Re: MarkInstall, Auto-Installed, and programs that misuse FromUser
On 13 November 2012 20:00, David Kalnischkies
<kalnischkies+debian@gmail.com> wrote:
> On Mon, Nov 12, 2012 at 6:22 AM, Daniel Hartwig <mandyke@gmail.com> wrote:
>> On 8 November 2012 07:39, David Kalnischkies
>> <kalnischkies+debian@gmail.com> wrote:
>> I do not 100% like the idea of pushing (3) entirely to the frontends;
>> it is fairly sensible, if only it didn't cause problems some times.
>> Anyway, any change to the semantics of MarkInstall is post-Wheezy
>> material, so maybe a better solution will come up in the meantime.
>
> That is the question: Is it really post-wheezy material?
There are almost no recent bug reports about auto-installed outside
of aptitude. Ubuntu's update-manager has one old report, filed as a
self-note by one of the developers. There are no user comments or
activity on that report. Another couple of developers recently noted
that their systems (using Ubuntu's update-manager) indicate many
libraries are manually installed when they should rather be auto.
Given the lack of user feedback on this I'd say that it does not
cause a very major inconvenience and is more of a technical issue
with the library.
> As you said in the first quote, (3) might make sense, but isn't what
> most libapt-users expect.
To clarify, this is only where there is no distinction between
MarkInstall and “MarkUpgrade”. For example, python-apt (almost?)
expects and documents that MarkInstall is (3)-always, and provides a
MarkUpgrade for (3)-never [1]. Aptdaemon makes the same distinction.
> Most of them seem to be in depth-freeze stasis
> given the seldom use of the FromUser bit causing it to be always set as it
> is the default.
> I wonder if the (3)-sometimes was hidden well enough so that libapt-users
> actually expected a (3)-never and got that most of the time.
>
I don't know. It is hard to tell what libapt-users expect without
their explicit feedback (hello, deity@). Looking at:
- the source code of various libapt consumers;
- python-apt documentation for mark_install; and
- comments in the “MarkInstall with FromUser set to true” bug against
aptitude;
it seems that some developers expect (2) and (3)-at-least-sometimes,
and there is very little indication whether anyone is thinking about
(1) (python-apt does not mention it at all).
Sensible end-users should expect that “install pkg” is (3)-always.
> Maybe it is better to revert the default behavior to (3)-sometimes as
> discovering all the hidden "broken" usages and fixing those in freeze might
> not be the best move. It wasn't done before freeze so I doubt it will be now.
Indeed this (or doing nothing) seems the only plausible action for
Wheezy. Reverting to (3)-sometimes will “fix”:
- bulk “mark for upgrade” operations in, e.g., synaptic;
- saving and loading state (only synaptic has problems here AFAICT).
It will not fix the python-aptdaemon bug, or consumers of that (more
of an Ubuntu problem, since Debian does not really use it). IMO the
fix for [2] is worth pushing to Wheezy, though I would appreciate
another developer's opinion on that.
Using codesearch.d.n, there are fewer than thirty relevant call sites
for MarkInstall, mark_install, and mark_upgrade. A quick scan of
these, and my previous investigation, indicates that most are ok, that
they are usually *install* requests coming directly from the user.
>
> With a config option we could make MarkInstall behave in regards to
> (3) in the states -never, -sometimes, -always with defaulting to -sometimes
> for wheezy and worry about what to do with the default after wheezy.
… without hitting _config on every call, as the hash lookups will
seriously slow down bulk operations (lots of these in aptitude). I
don't think having this configurable is that useful for Wheezy, most
consumers that are aware of the issue already take steps to control
auto-installed (i.e. apt-get, aptitude, python-apt, etc.).
>
> apt-get and aptitude as "good" citizens can then choose whichever mode they
> like. Clean might be something else, but overriding user settings is not nice;
> but it is what libapt currently does even if it is not entirely its fault.
Perhaps the clean, long-term solution is to follow python-apt:
- MarkInstall is (3)-always;
- explicit MarkUpgrade in libapt, with (3)-sometimes or (3)-never; and
- update frontends to distinguish between install and upgrade (e.g.
permit “apt-get upgrade package …”, already in aptitude, others).
It then becomes clear for developers and end-users, and across all
frontends, that install means “install the candicate version and keep
this package installed.” Always. This is actually quite a small
amount of work due to existing python-apt support and the lack of use
of MarkInstall amongst direct consumers of libapt (i.e. cc programs).
> So strictly speaking this is a release-critical bug at it looks like it is
> easier to "fix" in libapt than in potential a good portion of all libapt-users.
I think this is ok. It would be great to hear from the rest of the
list, especially other frontend developers.
Regards
[1] Re: MarkUpgrade should be (3)-never
Package foo is auto-installed and upgradeable. Upgrading foo also
requires upgrading it's reverse dependencies. Those upgrades no
longer depend on foo. There is a case for “MarkUpgrade(foo)” to
upgrade the reverse-deps and remove foo. The local admin should
expect this and ensure that desired packages are not marked
auto-installed or remain depended on by a (local) meta-package.
[2] http://bugs.debian.org/685044
Reply to: