Re: Bits from the FTPMaster meeting
Gerfried Fuchs wrote:
> Hi!
>
> 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.
The rationale is that the turnaround time would get smaller. Currently
the built package waits for the buildd admin to manually sign. A smaller
turnaround time would at least affect transitions, binNMUs and testing
migration in general.
AFAIK binary packages would only be thrown away for sourceful uploads.
There still needs to be implemented a solution regarding the
Architecture: all packages and actual testing and preparation by the
wb-team to get actual autosigning on any buildd btw.
>> 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.
The solution consists of keeping the Architecture: all packages in the
Packages files as long as the corresponding Architecture: any packages
are not installed in the archive if any (actual implementation is a bit
more involved due to some corner cases).
Cheers
Luk
Reply to: