Hi, * Benjamin Mesing [2012-06-11 22:42 +0200]: > thanks for the extensive testing and information. I have already fixed > many of your reports in SVN
great! Please remember that Debian freezes in the second half of June and that a release team member recently wrote that uploads thus should be done before the 15th of June (yes, this is still the first half ...). > > * It fails silently fails to remove packages (after installing > > aptitude, before it complained about the missing aptitude). > > The installation tool (apt vs. aptitude) is configurable within > packagesearch. I have changed the default to "apt" since packagesearch > depends on apt anyways. I have also improved the error message, when > aptitude is not available to point to the configuration dialog. Sounds sane. > However, I cannot reproduce the silent failure to remove the package > after installing aptitude. I replaced /bin/su and /usr/bin/aptitude with a script that writes the invocation name and the arguments to /foo. The content of /foo does not change if I try to install or remove a package using packagesearch. Maybe I just don't understand how packagesearch should be used. If I use it correctly, possible explanations include that packagesearch don't like to be run by root or that a minimal environment (e.g., without $SHELL) is not sufficient, ... > I do not know, if I have a multiarch system ... but that this problem is multiarch related seems to be most likely, or in other words, that I have a multiarch system and you do not. dpkg --print-foreign-architectures will print the foreign architecture if you have a multiarch system. > (deborphan reports the :arch tag), but I guess this has nothing to do > with it anyways. dpkg and apt are supposed to run on the system they do act on, deborphan acts on the status file you feed to it and if you do not specify one it defaults to /var/lib/dpkg/status. To detect multiarch, deborphan reads all Architecture: fields and counts the number of distinct values. Accordingly, deborphan might detect a system not to be multiarch if dpkg has been told to enable multiarch but no foreign package is installed. You case seems to be the opposite, which should not happen if your system never was multiarch (you would know if it was). The output of the following command would be interesting (replace amd64 with i386 if you run a 32 bit Debian): egrep '^(Package:|Version:|Architecture:)|^$' /var/lib/dpkg/status | perl -00 -ne 'print if /^Architecture:/m && !/^Architecture: (all|amd64)$/m' | cat -A The first paragraph of http://wiki.debian.org/Multiarch/Implementation describes how to enable multiarch. To install a foreign package you could for example run 'apt-get install sc:i386'. Doing this in a newly created chroot prevents possible problems on your productive system if things don't work as expected. > > * It complains that the file list for $package is not available for > > co-installable multiarch packages. I assume all you do is listing > > the file content of /var/lib/dpkg/info/${packagename}.list. For > > co-installable multiarch packages, this is not enough, for example, > > /var/lib/dpkg/info/devscripts.list would be found, but > > libapt-pkg4.12:amd64.list in the same directory would not be found > > using this approach. > > I quick fixed that: packagesearch now scans for <packagename>[:*].list > and takes the first match.. Given that, for example, libc6:amd64.list and libc6:i386.list contain different filenames, doing this properly might be worthwhile for Wheezy+1. > > packagesearch as deborphan frontend works as expected, except of above > > noted general problems. On multiarch enabled systems, deborphan/Wheezy > > prints package names with architecture suffix, for example 'vim:amd64' > > instead of 'vim'. On non-multiarch systems, it omits this architecture > > suffix. > > I have quick fixed this by removing the trailing :arch part, even > though, in the long run, it might be desirable to include > arch-information. JFTR: deborphan does not display a package as orphaned that is installed for multiple architectures if it is not orphaned on all architectures. Unless the user uses an possible future option to do tell deborphan otherwise, this behaviour should never change. > Thanks for your help Thanks for fixing things that fast :) Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
