Control: severity -1 wishlist
Control: tags -1 + wontfix
Hi Mika,
2011-03-14 14:10 Michael Prokop:
Package: aptitude
Version: 0.6.3-3.2
Severity: normal
/etc/apt/sources.list.d/foo.list contains something like:
deb https://$USER:$PASSWD@$MIRROR internal main
and because of confidential information ($USER/$PASSWD) the file is
read-only for root (600).
Another reply was already posted a few years ago with a workaround /
better way to achieve this.
I guess that you solved the problem in some other after these years, but
for the record...
Now running:
% apt-cache search foobar
lxmusic - The minimalist music player for LXDE
man2html - browse man pages in your web browser
works as expected, since the package information of the $MIRROR
above is available in /var/lib/dpkg/status accessible for anyone
anyway. Running strace shows that the file is being read but
apt-cache doesn't care too much:
open("/etc/apt/sources.list.d/foo.list", O_RDONLY) = -1 EACCES (Permission
denied)
Now apt-cache doesn't behave as described above:
$ apt-cache search aptitude
E: Could not open file /etc/apt/sources.list.d/04-debian-debug.sources - open
(13: Permission denied)
E: Malformed stanza 1 in source list
/etc/apt/sources.list.d/04-debian-debug.sources (type)
E: The list of sources could not be read.
W: You may want to run apt-get update to correct these problems
E: The package cache file is corrupted
Running aptitude fails with:
% aptitude search foobar
E: Opening /etc/apt/sources.list.d/foo.list - ifstream::ifstream (13:
Permission denied)
E: Opening /etc/apt/sources.list.d/foo.list - ifstream::ifstream (13:
Permission denied)
E: The list of sources could not be read.
I consider this inconsistent with apt-cache's behaviour (without
judging who's right :)).
It would be nice if aptitude either doesn't error out or if that's
not an option provide a way how to ignore that error.
aptitude search does quite a few things extra compared with apt-cache
search due to the use of patterns, which includes searching for
auto-flags, holds, forbid versions, origin, user-tags, relationships of
packages (depends, rdepends, conflicts), is garbage (not required by any
other installed package; which involves many structures needed in
typical conflict resolutions), or if is obsolete (cannot be downloaded),
among others.
Comparing apt and aptitude search is not an apple-to-apple comparison,
and that they behave in behaviours and errors is nothing surprising.
(Funnily enough, they don't diverge in behaviour by now).
Even if perhaps reading the source.list* is not strictly needed
(intuitively I don't think so, but I didn't check carefully), it has to
initialize a vast amount of data structures and classes, including its
own and libapt's, some of which require initializing source lists, or
might be needed later for the vast majority of operations that can be
done with aptitude. The initialisation code used in "search" is the
same as when initialising other parts of aptitude, without having
separate code paths for some of the operations which don't need 100% of
the structures initialised.
So I am sorry, but don't think that it's a net gain for aptitude to
address this bug, and have to duplicate code or complicate the
implementation (both of which can lead to new problems and are of some
maintenance burden) because of this specific problem, which seems quite
a corner case.
Cheers.
--
Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
