[Pkg-postgresql-public] buildd path too long (postgresql-9.3 FTBFS)

[Roger Leigh]

On Sun, May 12, 2013 at 12:04:39PM -0700, Christoph Berg wrote:
> Re: Roger Leigh 2013-05-12 <20130512185111.GI21041 at 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.

Sure, the build path uses a lot of that space.  This certainly doesn't
help.  But it's also still a fact that the build is *not deterministic*
if it creates sockets in its build path.  I mean in general, not just
in the context of Debian buildds.  I might be doing the build in my
home directory which has an extremely long path.  The point I want to
make is that the package is already broken in certain circumstances,
and the long buildd path just exacerbates a pre-existing problem.

> > 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.

It's probably a small tweak to the Makefile and/or source, and it
will benefit people building PostgreSQL outside Debian as well.

> 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.

The information in the path is there for a few reasons.  These include:
- finding the correct build tree if you need to go in there manually
- having multiple versions build in parallel
- having the same version build in parallel
- having multiple users able to build the same package at the same time
i.e. to avoid path conflicts; when you have the same buildd building
the same package for multiple architectures and distributions, these
are there for a reason.
We could replace the long path with an opaque job ID, but that would
make finding the tree by hand annoying.

If we were to remove the additional information, that would save a bit
of space.  But it would still only take a long version number or a
change in the upstream source layout to trigger the issue again--that's
what I mean about it only papering over what is really an upstream
issue.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux    http://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-    GPG Public Key      F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800