Bug#545464: Zombie cross packages
Neil Williams <codehelp@debian.org> writes:
> tag 545464 - patch
> thanks
>
> The plan for the transition will be:
>
> 0. fix dpkg-cross to properly create the packages that should have been
> made in the latest release.
>
> 1. dpkg-cross puts no files in the new multiarch locations, no matter
> what - this prevents conflicts when the new version of dpkg is able to
> install the packages containing those multiarch locations.
>
> 2. dpkg-cross enforces OLD behaviour for all packages no matter what -
> this preserves the old paths for the current compilers.
>
> 3. packages that contain multiarch metadata in debian/control get an
> explanation in the -cross package description and that's it - these
> are henceforth termed zombie cross packages because they are only
> needed to support remaining reverse dependencies.
That can not happen till dpkg can actually install multiarch packages
for foreign architectures. And even then it should be an option so one
can convert packages for use with older dpkg.
So by default even package with multiarch metadata must use the OLD
behaviour unless configured to use zombie packages. Anything else will
not result in something functional now.
> 4. need am emprunecross helper to identify these zombie cross packages
> and delete them all. (emprunecross removes all -cross, the new helper
> needs to be in dpkg-cross and far more precise.)
Do we? There is the automatic tracking in apt-get/aptitude. There is
deborphan and debfoster. And the normal use case is a chroot that needs
a good spring cleaning every now and then anyway.
> 5. need zombie package-aware dpkg-checkbuilddeps
Long term.
> 6. At some point *AFTER* dpkg has support for installing the true
> multiarch packages in their correct (new) locations
> (e.g. usr/lib/$triplet), then a new version of dpkg-cross can be
> prepared that drops the old location from any new zombie packages
> created after that time. All zombies (and only zombies) will be
> made from multiarch-compatible packages and zombies created by the
> final version of dpkg-cross will be truly empty.
Zombie packages should have no files in them (other than maybe
/usr/share/doc). Anything else would not be the empty dummy packages
previously discussed.
> Item 5 will wait, the important parts are:
>
> a: current compilers work with current locations and gradually learn to
> look in the new multiarch locations - packages or test chroots can be
> manually fettled to have files in the relevant locations for testing
> purposes. Alternatively, test with a patched dpkg that can use the
> multiarch package itself.
>
> b: when a version of dpkg is uploaded that understands how to install
> an armel mulitarch package alongside the amd64 one, the cross package
> will not prevent installation of the armel mulitarch package.
Additionally the -cross package should depend on the same version of the
non-cross package. The multiarch amd64 and armel packages will also be
locked to be the same version. Put both together and you ensure that
there is only one version of a library present at any one time for all
architectures. That way it doesn't matter if the compiler use the files
from the old or new location.
> c: The aim is to have the wrapper for removing these zombie packages in
> the version of dpkg-cross which makes it into Squeeze. Users are
> advised to run the wrapper frequently to reduce problems of having a
> new version of the headers in the multiarch location and a previous
> version in the old cross location. It is not possible to impose a
> arch-specific conflict in the zombie cross package but it might be
> possible for the multiarch package to conflict with the zombie cross
> package.
Not needed. See above. Official packages also can't have arch specific
depends or conflicts and won't have conflicts on all possible -cross
packages of themself. Multiarch dpkg requires that all architectures
must have the same version. So we only have to make sure the -cross
packages are that version as well (zombie or not zombie). A depends in
the -cross package does that.
> d: the patch for #545464 is wrong because it puts symlinks in the new
> location and the real files in the old location. This is unnecessary
> churn when this zombie cross package merely needs to contain the files
> for the old location and be deleted as soon as the reverse dependencies
> make that possible.
As said above. Zombie packages should be empty. And non zombie packages
have all files in the OLD dirs, even if the original deb has them in the
new dirs. By keeping the dirs seperate the multiarch package can be
installed later without a file overwrite conflict, as you said above. I
think that is an important feature.
> e: if this all happens during a SONAME transition for a particular
> package all bets are off - although it probably will work as the zombie
> cross package will replace the previous cross package with the new
> version headers.
Huh? If a SONAME happens at the same time then you have libfoo1,
libfoo1-armel-cross, libfoo2:amd64, libfoo2:armel and optional
libfoo2-armel-cross. None of them have any files in common and none of
them would would be upgraded automatically unless a reverse depends
upgrade says so. They can all be installed in parallel.
> f: essentially, the perennial problem of not being able to
> automatically upgrade -cross packages remains as problematic as ever
> because of #d and #e.
>
> The intention here is to not require a new version of dpkg-cross
> immediately that a new version of dpkg becomes available and to be sure
> that the new version of dpkg can install multiarch packages without
> dpkg-cross and -cross packages in general getting in the way.
>
> There was always going to be some pain during this transition for those
> who want to use dpkg-cross with Debian unstable (or squeeze until the
> freeze starts) - that pain is mostly restricted to manually having to
> update and upgrade -cross packages but as this burden is not new, I
> don't see that as a barrier. It just becomes possibly more of an issue
> than previously.
And apt-ma-emu solves that part.
MfG
Goswin
PS: The only thing really required is to move files from
/usr/lib/triplet to /usr/triplet/lib in -cross packages in
dpkg-cross. Anything else is just nice.
Reply to: