Re: MarkInstall, Auto-Installed, and programs that misuse FromUser
On 8 November 2012 07:39, David Kalnischkies
<kalnischkies+debian@gmail.com> wrote:
> As the changelog hints (3) was actually already in action sometimes:
>
> if(FromUser)
> {
> - // Set it to manual if it's a new install or cancelling the
> - // removal of a garbage package.
> - if(P.Status == 2 || (!Pkg.CurrentVer().end() && !P.Marked))
> + // Set it to manual if it's a new install or already installed
> + if(P.Status == 2 || Pkg->CurrentVer != 0)
> P.Flags &= ~Flag::Auto;
> }
> else
>
> P.Marked is a flag used by the AutoRemover which basically means that
> the package wasn't visited (which isn't the same as P.Garbage which
> means that the package can be autoremoved) -- both are usually updated
> only after the last active action-group is destructed.
>
> I found this pretty unintuitive for emit this side-effect as in various
> situations the "future" marking state will differ from the one we see
> while MarkInstall is executed and is not what we want even if we assume
> it is a good idea to only mark packages as manual if they weren't
> useful before to satisfy dependencies as it doesn't cope well with
> changed dependencies.
Interesting, I had overlooked that. I agree that it does make more
sense to have (3)-always, especially given the relevance of the Marked
state changing.
There are a few instances of similar code in aptitude which appear
redundant now that this is in libapt. Those will have to be checked
before any removal of this from libapt. I doubt it was anticipated
that the original move would cause so much trouble later!
>
>
>> - restoring previously saved selections (dselect, aptitude do this
>> on load; synaptic --set-selections);
>
> Unrelated intermezzo-comment:
> apt-get has a dselect-upgrade, too. The idea was/is that a user marks
> specific packages for install/removal here; therefore it is like
> giving all these packages on the commandline.
Looks like aptitude could learn a little something from that process,
although it is attempting to merge two saved states.
> If we think about it, the alternative to this would be to mark all
> packages as manual, that can't be what we want either.
Indeed, this is the danger at the moment using MarkInstall for
selective upgrades.
>> Moving forward, I see three options:
>> - move (3) to each frontend which desires that behaviour,
>> i.e. apt-get.cc (duplicates work, maybe problems);
>
> After wading though code (and fixing some more or less esoteric issues in
> apt-get itself related to this) I think the first one is the simplest and
> most expected option. The obvious alternative is to revert to the P.Marked
> dependency as before, but this still feels like a pretty strange logic and
> is after all just a (3)-sometimes instead of (3)-always as it is now.
> It's just that this (3)-sometimes is the original implementation proposed
> by Daniel and committed in 2005 so I still wonder what the intend is/was …
I suppose the concern was to balance keeping auto-installed some times
and not having direct requests disappear ever. (3)-always is much more
predictable, and very useful, but does not fit well with general use
of MarkInstall/FromUser.
In a sense, this is an attempt to accomodate “MarkUpgrade”, where the
preference is to keep auto-installed, inside of MarkInstall.
Python-apt and aptdaemon implement their own MarkUpgrade to make these
semantics explicit.
>
> For apt-get at least this isn't additional work as it already ensures that
> packages given on the commandline are marked as manually installed, in fact
> it is even better as it makes this a bit more predictable (as some options
> disable this and a message is shown to notify the user about this MarkManual).
This will be a bit of work in aptitude to tidy up, if (3) is removed.
But that is only a small matter of coordination.
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.
Of course fixing the hacks, especially the very broken one in
python-aptdaemon, certainly can (and should?) go in for Wheezy, as
these have wide-impact through programs like update-manager.
Regards
Reply to: