Re: Roger Leigh 2013-05-12 <[🔎] 20130512185111.GI21041@codelibre.net> > This issue has come up several times over the years. We can shorten > the paths a bit, but that's really just papering over the problem; > a long version number or an NMU could push it back over the limit. > We need a solution that will work under all circumstances, not just > some of the time. I don't buy that argument. While the length of unix socket paths is limited, the problem here is really that buildd is eating almost 3/4 of that itself. If it would leave more than a 30 (= 107-77) characters for use, packages had a real chance of building unmodified. > The main problem here is the assumption that it's safe to create a > socket inside the build tree; this is not the case. I would suggest > that upstream either create the socket in /tmp or have a variable > like PG_BUILD_SOCKET_PATH which can be overridden to make it use > /tmp. This would guarantee that the path limitation would never > be reached. This seems like much more effort than just reducing the length of the buildd base path. Does the long buildd base path there have any real advantage? I don't think people go looking *there* all the time and really want to see "oh package X version Y arch Z" is building there now. They will most likely have other means to get that information. Christoph -- cb@df7cb.de | http://www.df7cb.de/
Attachment:
signature.asc
Description: Digital signature