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

Re: Splitting the emdebian-tools sources



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: pgpJZz2NPSk1E.pgp
Description: PGP signature


Reply to: