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 <jo...@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, Rhonda -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
