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

Re: Bits from the FTPMaster meeting


 First of all, thanks for this great roundup. There are just some few
questions that popped up in my mind that I hope haven't asked yet
(wasn't able to check all the responses completely ...). Sorry if there
are duplications, a reference to the answer for easier tracking would be
appreciated, though. :)

* Joerg Jaspert <joerg@ganneff.de> [2009-11-15 16:15:35 CET]:
> source-only uploads
> -------------------
> The current "winning" opinion is to go with the source+throw away
> binaries route.  We are close to being able to achieve this, it is
> simply that it has not yet been enabled.  Before any version of this
> can be enabled, buildd autosigning needs to be implemented in order
> that dak can differentiate buildd uploads vs maintainer uploads.

 I am a bit confused with respect to how buildd autosigning is required
for this. It makes it sound somehow like it would affect porter binary
uploads. Is this the case or am I reading too much into this? What's the
rationale for the requirement of autosiging needs, and would porters
still be able to upload binary-only without having them thrown away
because they aren't signed with a key in the buildd-keyring? It's
unfortunately not too uncommon that some buildds have issues over a
longer period of time, and being able to help while that's the case is
what I consider an important feature for a porter.

> Tracking arch all packages
> --------------------------
> #246992 asked us to not delete arch all packages before the
> corresponding (if any) arch any packages are available for all
> architectures.  Example: whenever a new source package for emacs23
> gets uploaded the installation of the metapackage emacs_*_all.deb
> breaks on most architectures until the needed Architecture: any
> packages like emacs23 get built by the buildds. That happens because
> dak removes all arch: all packages but the newest one.

 What exactly is meant with deleting here? From the pool? Or does it
mean that the Packages files will keep all versions of the arch all
packages in them and thus reducing the amount of uninstallable packages?
The later would be greatly help with regular reports of uninstallable
packages that weren't yet built and the old binary package depending on
the old arch package which otherwise wouldn't be available anymore. From
what I understand (and tried) apt does the right thing and chooses the
most recent versions in cases where it doesn't matter anyway.

 Thanks in advance for clearing up these questions, and again, thanks
for your work!

 So long,

Reply to: