Hi Carsten,
thanks for the extensive testing and information. I have already fixed
many of your reports in SVN
> * 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.
However, I cannot reproduce the silent failure to remove the package
after installing aptitude. I do not know, if I have a multiarch system
(deborphan reports the :arch tag), but I guess this has nothing to do
with it anyways.
> * 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..
> 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.
Thanks for your help
Ben
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
