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

Bug#504460: #504460 apt-utils: include apt-listrepository



On Wed, Apr 07, 2010 at 02:21:58PM +0200, David Kalnischkies wrote:
> Other problems:
> 2) dpkg --get-selections lists more than only the installed packages
>  (hint: deinstall) but sounds as this wouldn't be requested.

Yes, displaying them is not the purpose of this script.

> 4) The name is not good (lists repositories? really?)

There has been some discussions about the name in 2004.  Everyone
involved in these discussions seemed to be happy with this name.  Maybe
someone comes up with a name that better describes "apt, please show me
from which repository I installed which packages" or "apt, please list
all installed packages with the corresponding URI, distribution and
component".

> 3 is partly guesswork as i can't convince the perl-script to accept my
> crazy apt setup, so i don't know what it will print in the end ...

Your "guesswork" is rather good but there are additional information
displayed:

    carsten@taz[sid]:~> apt-listrepository | sort -bk2 | tail -n4
    zsh                                 http://ftp.de.debian.org unstable/main
    sun-java6-bin                       http://ftp.de.debian.org unstable/non-free
    sun-java6-jdk                       http://ftp.de.debian.org unstable/non-free
    sun-java6-jre                       http://ftp.de.debian.org unstable/non-free

(sort -bk2 sorts the output by the repository, I think this should be
default if apt-listrepository gets rewritten or integrated in apt-cache.
Sorting by the package name also seems reasonable, but sorting the
output of a command by the first column is a lot easier for Joe Average
User than sorting by the second column and by making the hard one
default all the Joes and Janes out there combined save a lot of time.
I also consider this output sorted by the second column more useful in
most cases.)

> but here we go, apt-listrepository in python…

    carsten@taz[sid]:~> apt-listrepository.py | grep -E 'zsh|sun-java6'
    sun-java6-bin 6.18-4 ftp.de.debian.org
    sun-java6-jdk 6.18-4 ftp.de.debian.org
    sun-java6-jre 6.18-4 ftp.de.debian.org
    zsh 4.3.10-11 ftp.de.debian.org

As you can see in the output of the first command, I use zsh from
unstable/main and sun-java6-* from unstable/non-free in my sid chroot.
The output of the python version misses this relevant information, it
only shows that the versions of these programs I use were available from
ftp.de.debian.org last time I ran apt-get update.

Lets compare the output of both implementations:

    carsten@taz[sid]:~> diff <(apt-listrepository.py | cut -d' ' -f1,3- | sort) <(apt-listrepository | sort | sed 's/ \+/ /' | sed 's,http://,,' | cut -d' ' -f1,2) | grep -vE '/var/lib/dpkg/status|is not available online' | grep -vE '^[0-9cd,-]+$'
    Building dependency tree
    Reading state information... Done
    Reading package lists... Done
    < libhdf5-serial-1.8.4 ftp.de.debian.org
    > libhdf5-serial-1.8.3 ftp.de.debian.org
    < liblzma2 ftp.de.debian.org
    > liblzma1 ftp.de.debian.org
    < odbcinst1debian2 ftp.de.debian.org
    > odbcinst1debian1 ftp.de.debian.org

After investigating the differences it seems that the python version
seems to have some problems with deinstalled packages and display them
instead of similar named installed packages:

    carsten@taz[sid]:~> dpkg --get-selections|grep -E 'odbcinst1debian1|liblzma1|libhdf5-serial-1.8.3'
    libhdf5-serial-1.8.3                        deinstall
    liblzma1                                    deinstall
    odbcinst1debian1                            deinstall

The next problem is caused by using python's apt library without
unnecessary spending too much time to avoid minor pitfalls in use cases
not relevant for such a proof of concept.

The output of apt-listrepository could be feed to a script or a nagios
check, for such cases displaying information about building and reading
trees or lists is less interesting but instead annoying, especially when
it is hard to filter, as we can see if we take a closer look at one
line.

    carsten@taz[sid]:~> apt-listrepository.py 2>/dev/null | line | cat -A
    ^MReading package lists... 0%^M^MReading package lists... 0%^M^MReading package lists... 22%^M^MReading package lists... Done^M$

The output of apt-cache pkgnames is a lot more sane for noninteractive
usage.

> I am also unsure if it is really desirable to have apt-listrepository
> ... in an important package as the use case is pretty limited…

The output of the perl version is a lot more useful than the output of
the python version and since you did not see the former before you wrote
this sentence your judgement is quite comprehensible, though I hope you
changed your opinion in the meantime due the new facts.

I consider wanting to know which packages are installed from another
release (oldstable, backports, ...) to be a pretty good use case for it,
although one could be more verbose describing this use case.

Another one is "package a has been removed from squeeze, user doesn't
want to use packages without security support and thus wants to be
warned whilst upgrading from lenny to squeeze".  There has been some
discussions about this in the past but as far as I know there is no
solution besides reading the release notes or possibly some third party
scripts.

apt-listrepository alone does not solve this problem either, but in
combination with grep and a user being aware of this problem and able to
use pipes and grep this use case could be addressed.  An apt-cache
command `show-unknown' would it make easier for users to get this list
of locally installed packages without support.  The code for both
commands could be the same and I think it wouldn't make a significant
difference in code size to implement `show-repository' and
`show-unknown' or only `show-repository' (or whatever you choose as
name).

A possible next step to address this second use case could be
integrating the output of `show-unknown' into `dist-upgrade' if a user
upgrades to the next release, but not during regular dist-upgrades in
sid since this would be nerving.  The first idea that comes to my mind
is doing this if base-files is upgraded (since it contains
/etc/debian_version there must be a new version every stable release),
but this would be a really dirty hack, so we should probably wait with
this step until someone gets a better idea.

On Wed, Apr 07, 2010 at 04:57:46PM +0200, Julian Andres Klode wrote:
> I could rewrite it in C++ and include it in apt-cache as
> a list-repository command.

I would really appreciate seeing this as command in apt-cache in
squeeze, with or without the proposed additional command that only shows
packages not available in any repository.

The two existing versions could help you to it the right way in
apt-cache, the original one as one of the most useful hacks I've ever
seen and the very impressive python proof of concept done in only a few
lines of code.  Both have their minor pitfalls but don't suffer from the
pitfalls of the other version.  The perl version could also serve as
test by comparing its output to the output of the apt-cache command, at
least after both have been ppostprocessed to remove differences in white
spaces.

All existing apt-cache commands seem to be rather short, maybe something
like `showrepo', `showarchive', `showarch', `repository' or `archive' is
more adequate than `list-repository' or `show-repository' and instead of
`show-unknown' one could choose `unknown', `homeless', `unavailable' or
`unavial'.  My favorites are currently `showrepo' and `unavail', besides
the different meaning of `available' in dpkg.


Regards
Carsten



Reply to: