-----BEGIN PGP SIGNED MESSAGE-----
Gregor Hoffleit <[EMAIL PROTECTED]> writes:
> IIRC, during the big X11 package renaming, there was a need for some
> empty dummy packages. Should I use empty python-net etc. packages and
> urge the user to remove them when they are no longer necessary ? Or
> can I resolve the situation with "Replaces: python-net, ..." and/or
> "Provides: python-net, ..." and/or "Conflicts: python-net, ..." ?
Hmm. Well, there are two characteristics of this change that make it
a bit different than all the stuff that went on with X.
1. nothing is being renamed; the affected packages are only being
folded back into another, already-existing package.
2. the affected packages are being folded together, not split
apart or renamed.
The problem with the X renaming was that there was no really effective
way to tell when (a) a package had been renamed (eg. xfnt75 ->
xfonts-75dpi or whatever it's called now) or (b) an existing package
had been split up (eg. xbase). Your proposed reorganization doesn't
have either of those problems, because anyone upgrading Python will
necessarily HAVE to upgrade python-base.
Therefore, it appears to me that upgrading will handle itself, if you
make python-base conflict/provide/replace python-net et.al. When
someone upgrades python-base, dpkg will remove the old packages.
Meanwhile, if they try to upgrade any other part of Python, they'll
end up upgrading python-base too.
The other side of the coin, of course, is the dependencies of other
Python packages. Eventually, they will have to be fixed, especially
since many of them are probably versioned. You could, I suppose,
create dummy packages in order to keep existing software in potato
working until the dependencies are fixed, but it should not be
necessary to keep those dummy packages around forever (and certainly
all the third-party stuff should be fixed by the next release).
- --Rob
- --
Rob Tillotson N9MTB <[EMAIL PROTECTED]>
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: noconv
Comment: Processed by Mailcrypt 3.5.1, an Emacs/PGP interface
iQCVAwUBN2bVPnR+ngWruQ4VAQHpJwP/eXA9hOhn7VkBV3U8N93mDon6zGPdK4S9
yY0z6yq+h+0yByU7LdKy7DyVeHfgUdbAiq4Znu2j8YClt7YJ0Bf8ouWwi4otPboC
czDC5GLRK+H6UVeE4weB5FJ4ueHZZr05TkIw2o77srqe8vdVmnq2nB3+B7gFDCQm
lWBXAHGGnQQ=
=Dtvn
-----END PGP SIGNATURE-----
