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

Bug#545464: Zombie cross packages



Neil Williams <codehelp@debian.org> writes:

> On Wed, 10 Feb 2010 09:07:51 +0100
> Goswin von Brederlow <goswin-v-b@web.de> wrote:
>
>> > 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.
>
> Forget empty packages, zombies aren't empty, just zombies. :-)
>
> This is the example workflow for the current changes:
>
> (liblouis2 declares a Multi-Arch field and has it's files in Multiarch
> places, libqof2 is a plain pre-Multiarch library.)
>
> root@calvin:~/dpkg-cross-test# dpkg-cross -a armel -v -b liblouis2_1.8.0-1_armel.deb 
> Excluding: 
> Trying to build: liblouis2_1.8.0-1_armel.deb
> Going to convert liblouis2_1.8.0-1_armel.deb
> Extracting liblouis2_1.8.0-1_armel.deb
> Extracting information from control file
> Creating destination package tree
> moving symlink /usr/lib/arm-linux-gnueabi/liblouis.so.2.
> moving file /usr/lib/arm-linux-gnueabi/liblouis.so.2.1.0.
> Installing shlibs file
> Creating control file
> Creating md5sums file
> dpkg-deb: building package `liblouis2-armel-cross' in `./liblouis2-armel-cross_1.8.0-1_all.deb'.
> root@calvin:~/dpkg-cross-test# dpkg -c ./liblouis2-armel-cross_1.8.0-1_all.deb
> drwxr-xr-x root/root         0 2010-02-10 13:50 ./
> drwxr-xr-x root/root         0 2010-02-10 13:50 ./usr/
> drwxr-xr-x root/root         0 2010-02-10 13:50 ./usr/arm-linux-gnueabi/
> drwxr-xr-x root/root         0 2010-02-10 13:50 ./usr/arm-linux-gnueabi/include/
> -rw-r--r-- root/root     80556 2010-02-10 13:50 ./usr/arm-linux-gnueabi/include/liblouis.so.2.1.0
> lrwxrwxrwx root/root         0 2010-02-10 13:50 ./usr/arm-linux-gnueabi/include/liblouis.so.2 -> liblouis.so.2.1.0
> root@calvin:~/dpkg-cross-test# dpkg-cross -a armel -v -b libqof2_0.8.1-1_armel.deb   
> Excluding: 
> Trying to build: libqof2_0.8.1-1_armel.deb
> Going to convert libqof2_0.8.1-1_armel.deb
> Extracting libqof2_0.8.1-1_armel.deb
> Extracting information from control file
> Creating destination package tree
> Creating symlink /usr/arm-linux-gnueabi/lib/libqof.so.2 -> libqof.so.2.0.1
> Creating symlink /usr/arm-linux-gnueabi/lib/libqofsql.so.1 -> libqofsql.so.1.0.1
> Creating /usr/share/doc/libqof2-armel-cross/README
> Installing shlibs file
> Creating control file
> Creating md5sums file
> dpkg-deb: building package `libqof2-armel-cross' in `./libqof2-armel-cross_0.8.1-1_all.deb'.
> root@calvin:~/dpkg-cross-test# dpkg -c ./libqof2-armel-cross_0.8.1-1_all.deb  
> drwxr-xr-x root/root         0 2010-02-10 13:50 ./
> drwxr-xr-x root/root         0 2010-02-10 13:50 ./usr/
> drwxr-xr-x root/root         0 2010-02-10 13:50 ./usr/arm-linux-gnueabi/
> drwxr-xr-x root/root         0 2010-02-10 13:50 ./usr/arm-linux-gnueabi/lib/
> -rw-r--r-- root/root     42836 2009-07-07 00:11 ./usr/arm-linux-gnueabi/lib/libqofsql.so.1.0.1
> -rw-r--r-- root/root    245296 2009-07-07 00:11 ./usr/arm-linux-gnueabi/lib/libqof.so.2.0.1
> drwxr-xr-x root/root         0 2010-02-10 13:50 ./usr/share/
> drwxr-xr-x root/root         0 2010-02-10 13:50 ./usr/share/doc/
> drwxr-xr-x root/root         0 2010-02-10 13:50 ./usr/share/doc/libqof2-armel-cross/
> -rw-r--r-- root/root       262 2010-02-10 13:50 ./usr/share/doc/libqof2-armel-cross/README
> lrwxrwxrwx root/root         0 2010-02-10 13:50 ./usr/arm-linux-gnueabi/lib/libqof.so.2 -> libqof.so.2.0.1
> lrwxrwxrwx root/root         0 2010-02-10 13:50 ./usr/arm-linux-gnueabi/lib/libqofsql.so.1 -> libqofsql.so.1.0.1
> root@calvin:~/dpkg-cross-test# 
>
> ./liblouis2-armel-cross_1.8.0-1_all.deb is the zombie
>
> root@calvin:~/dpkg-cross-test# dpkg -I ./liblouis2-armel-cross_1.8.0-1_all.deb
>  new debian package, version 2.0.
>  size 44116 bytes: control archive= 541 bytes.
>      498 bytes,    14 lines      control              
>       82 bytes,     1 lines      md5sums              
>       21 bytes,     1 lines      shlibs               
>  Package: liblouis2-armel-cross
>  Version: 1.8.0-1
>  Section: devel
>  Priority: extra
>  Architecture: all
>  Maintainer: Debian Accessibility Team <debian-accessibility@lists.debian.org>
>  Source: liblouis
>  Depends: libc6-armel-cross (>= 2.4), liblouis-data-armel-cross
>  Provides: liblouis2-armel-dcv1
>  X-Multiarch: delete
>  Description: liblouis2 - multiarch zombie package
>   This package was generated by dpkg-cross as a zombie multiarch package.
>   .
>   Remove this package when there are no reverse dependencies left.

Please don't call it a zombie. It has no zombieish properties. It has
exactly the same contents and locations as when converted from a
non-multiarch liblouis2. It also has the exact same depends, provides,
conflicts, ... as when converted from a non-multiarch liblouis2. It is
also not save to remove this package as that would remove vital files.
The only difference is where file were located before conversion.

It also only becomes save to remove liblouis2-armel-cross when it has
pulled in the multiarch liblouis2:armel to provide the files and has no
reverse depends left. So the description is wrong too.

>> 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.
>
> Misunderstanding. Zombies use the old behaviour and there's no
> configuration step.
>
>> > 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.
>
> True but *every* -cross package shows up in the aptitude/synaptic
> local/obsolete list - that's the same list that emprunecross finds.
> Except that with aptitude/synaptic that list also includes locally
> installed packages like test builds and pre-upload versions. What we
> need to help people identify are *just* the zombie packages and then
> work out which of those have no reverse dependencies still installed
> and can therefore be removed.
>
>> > 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.
>
> No, that's changed. Sorry if that wasn't clear. Zombie packages contain
> files in the OLD locations.
>  
>> > 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.
>
> We've had this discussion before - there cannot be a cross-architecture
> dependency at this time.

And I'm not suggesting to add one. A plain libfoo-armel-cross "Depends:
libfoo (= 1.2-3)" will do. That will require at least some arch for have
a libfoo of version 1.2-3 and multiarch then requires all of them to be
version 1.2-3. Overall that ensures every libfoo.so.1.2 on the system
will be from 1.2-3. No version skew possible.

> http://lists.debian.org/debian-embedded/2010/01/msg00028.html
>
>> > 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. 
>
> Not essential but very useful and it is desirable.

I suggest making something that works for every transitional dummy
package in Debian and then building our dummy cross packages to fit the
same pattern. Checking the package has no files other than the required
files in /usr/share/doc/package and no reverse depends might do it.

That also wouldn't catch "zombie" packages which are still needed to
do the update to the multiarch libfoo:armel.

MfG
        Goswin



Reply to: