[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: throw away debs and source only uploads



Hi!

On Sun, 2011-04-17 at 11:20:07 +0200, Stefano Zacchiroli wrote:
> On Wed, Mar 30, 2011 at 04:18:34PM +0200, Stefano Zacchiroli wrote:
> > > The main decision which needs to be made is whether, as a project, we
> > > want source only uploads or to throw away DD built non-all debs.
> > > There's not entire agreement amongst the ftpmasters about this (I err
> > > on the side of the source-only uploads to avoid making people waste
> > > time and bandwidth but that's not the only opinion).
> > <snip> 
> > > Once a decision is made, implementation is easy, but I'd like some
> > > form of consensus before we go down that route.
> 
> Further round of update on this one, after some more discussion on list
> and a brief chat of mine with Mark.
> 
> - There seems to be consensus to go ahead with throw-away debs; they
>   require a bit of work though so either be patient or, better,
>   volunteer with FTP masters to help out with the implementation of the
>   remaining bits.

I think this was mentioned in some previous incarnation of this
discussion, but throwing away debs unconditionally, or at least w/o
having a way to specify they must not be thrown away is going to be
an issue when bootstrapping packages. Those cases where we have
a cyclic build dependency chain, which is not uncommon:

  1) Some compilers written in the same language they target.
  2) Build tools: pkg-config Build-Depends on libglib2.0-dev,
     libglib2.0-dev Build-Depends on pkg-config. pkg-config used to
     bundle an ancient glib 1.x to be able to automatically bootstrap
     but that was removed with some recent upstream release.
  3) IDL generators: mig Build-Depends on gnumach-dev, gnumach
     Build-Depends on mig.
  4) ...

Having to request ftp-masters each time one of these is first
bootstrapped anew on an architecture is going to be annoying, both
for the porter/packager and for the ftp-masters.

regards,
guillem


Reply to: