On Fri, Dec 21, 2012 at 4:45 AM, Daniel Hartwig <mand...@gmail.com> wrote:
> On 20 December 2012 22:19, Axel Beckert <a...@debian.org> wrote:
>> So since apt is not essential, but aptitude needs some binaries out of
>> that package to perform very common actions, aptitude must have a
>> dependency on apt
>
> Such a dependency belongs to libapt-pkg, or to move the basic
> method drivers to that package. It is libapt-pkg that uses
> them, aptitude only requests to acquire some file and knows nothing
> about any of these drivers or their usage.
>
> This otherwise requires adding such a dependency to all libapt-pkg
> consumers.
>
> I recall this may have been discussed this year, though do not
> recall the outcome.
The outcome was the usual one:
Would be nice, but needs work which probably nobody has the time for.
Even more so as I have (temporary) left so we even lack a nobody for
not having the time/motivation to do so currently as it seems …
(Not explicitly said of course and just mentioned in the discussion
resulting in libapt-pkg breaking apt instead of depending on it, so
you are absolutely not dreaming but might be a few months ago)
If we really wanted to solve this problem fast we should just mark
apt as proper Essential as it behaves like that. Currently only 13
machines participating in popcon don't have it installed …
But while this solves this "problem", it just makes everything else
more complicated so this is of course a bogus solution – just ignore
the issue and let users shooting oneself in the foot if they really want to.
(To get that into perspective: We have 61 required packages (25 of them
are also Essential) – apt is not one of them but Top 29, which means it
ranks above half of the required packages set … in Vote it is even Top25 …)
>> (or at least recommend it).
>
> Yes, packages other than apt do also provide method drivers, and—at
> least in theory—could provide an alternative to the base set.
The most likely example is apt-transport-https I guess –
which transport is needed is a user configuration choice:
In a file (sources.list) which is at least documented by 'apt'.
Which is the actual problem: Configuration. Without apt installed you
miss some folders and files which technically aren't needed, but in
practice are the default configuration for libapt-* which is expected
to be present (like never-autoremove and all that stuff).
If I would have unlimited time there would be a libapt-bin which would be
M-A:foreign and includes the methods. There would also be a libapt-common
which includes the config files and directories so APT alternatives
(not aptitude, I mean stuff like cupt) have a chance to depend on what
they actually use. There would also be no libapt-{pkg,inst} split and later
I would build a motivation-machine and fly on my griffin to university …
Sadly, for now my money is on the "griffin"-thing to happen first.
Best regards and happy package management :)
(I wonder if this could be a diversity-statement compatible seasonal greeting)
David Kalnischkies
P.S.: I read aptitude-devel so I know the context, but a deity@ reader just
sees a "Processed: …" mail lacking all the context, so it might be a good
idea to sent your reassign mails to ${package}@packages.debian.org, too, as
these Processed mails are pretty easy to skip over.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
