[Aptitude-devel] Bug#618342: aptitude: inconsistent behaviour with apt-cache on non-readable sources.list file

[Manuel A. Fernandez Montecelo]

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.montezelo at gmail.com>