On Wed, 25 Mar 2009 09:50:30 +0000 Neil Williams <codehelp@debian.org> wrote: > The emdebian-tools source package currently generates 12 binary packages > with three distinct roles: > > 1. keyring packages - content very rarely changes and the udeb needs > > 2. emdebian-tools - the original package > > 3. emdebian-rootfs It's actually quite difficult to do this properly, even with the support of the Emdebian repository. So, whilst the new source packages are waiting in the Debian NEW queue, emdebian-tools could be a problem in Debian - the only way I can see of doing it is: 0. upload the final packages to Emdebian with the split already implemented and at a version higher than the upload going into unstable. (In effect, this is easy because there is a longer delay between an upload to Debian and the new package appearing than for Emdebian - which is almost instantaneous. The two uploads can therefore be simultaneous.) The actual build for this upload will be a branch in SVN, merging back into trunk/ only when the final Debian upload has been accepted. 1. upload a broken emdebian-tools to Debian unstable and prevent migration into testing with a stalling RC bug. This meta-package will Provide: every package we need but merely act as a way of getting the real packages from the Emdebian repository. Users will get dummy scripts for those scripts that are migrating to new source packages. The dummy scripts will tell them to get the real package from Emdebian during the transition. This won't be a problem because the Emdebian repository will still be added to their apt sources anyway so it's only a question of updating and upgrading - indeed, emsetup will do this for new users anyway. The packages in Emdebian will therefore have Replaces: emdebian-tools (<= 1.8.0) 2. Once the Debian upload has caused the migrated binary packages to be removed from the archives, upload the new source packages to the Debian NEW queue. These can't clear NEW until the relevant binary packages have been removed from the listing of binaries generated from the emdebian-tools source package. This upload will, again, be a lower version than the version already in Emdebian so existing users will never see it. 3. When those clear NEW, re-upload the working version of the emdebian-tools source package without the Provides, still behind the relevant upload in Emdebian. 4. Only once everything has cleared up, make a final upload to Debian that is ahead of the Emdebian version and which closes the RC bug. So I'll do this as Debian uploads using the 1.8.x series and the Emdebian uploads using the 1.9.x series and then migrate to 2.0.0 as the final uploads to Debian with the transition complete. As it's so involved, I'm wondering if the Grip packages should be split out at the same time (as a pre-emptive move in case we would need to do this again sometime in the future). Basically, as far as anyone already using the tools is concerned: * 1.8.x is a no-go area. You shouldn't see it, you shouldn't install it and you shouldn't care about it. Everyone will be on 1.9.x until Debian catches up. * When there are queries on the mailing list or IRC, please reinforce this message, 1.6.x is fine. 1.7.x will just be skipped. 1.8.x is transitional and not intended to be functional. 1.9.x will pick up from 1.6.x and will be available as an upgrade from Emdebian as soon as this all starts. Everyone should be using either 1.6.0 from Squeeze or 1.9.x from Emdebian unstable until 2.0.0 becomes available in Debian unstable. Whatever happens, ignore 1.8.x and tell everyone to upgrade away from it - you go from 1.6.x to 1.9.x without caring about the ones in between. Hopefully this will all be over as quickly as we can get things through NEW. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpHz5lLfePIo.pgp
Description: PGP signature