Hi David, Thank you for taking the time to reply. I now that must be a low priority bug on apt's list.
On 6/2/20 4:48 PM, David Kalnischkies wrote:
> Hi,
>
> On Sun, May 31, 2020 at 11:45:23AM +0200, Baptiste BEAUPLAT wrote:
>> On Sat, 17 Dec 2011 15:56:22 +0200 =?utf-8?q?Martin-=C3=89ric_Racine?=
>> <martin-eric.rac...@iki.fi> wrote:
>>> The --fix-policy option is not documented in the apt-get man page.
>>
>> Please consider applying the following patch that documents the
>> --fix-policy option.
>
> The problem with this option and hence the documentation is that
> "policy" is a very bad word here. I said on IRC then I mentioned
> & explained that option that it is 'apt-speak', but I meant that this is
> something only the code & debug messages use – and even those aren't
> uniformly using it as the code calls these dependencies also "important"
> (vs. "critical"). In the code this makes sort of sense, but I wouldn't
> like to expose a user to the notion of "important" as we use that word
> for yet more other confusing things (which is probably why the code
> isn't using it all the time either).
>
> From a user point of view "policy" refers to apt_preferences, at least
> that is what we have taught them via "apt{-cache,} policy" for years and
> the code happily uses it in that sense everywhere as well.
>
> A --fix-policy suggests hence it does something with apt_preferences
> which it doesn't as the "configured policy" there is not at all about
> Recommends/Suggests.
I feel like I understand a bit better the issue here. Basically user and
technical (in-code) definition of policy is different. That option
should not be called like that.
> So, instead of documenting, I would like to "remove" this option:
> The functionality as-is is not that great as it is all-or-nothing which
> is rarely useful. I would prefer a command which will act on given
> packages instead (and only if non are given on all) with a more sensible
> name.
I do think there is a use case here. I'm sure some of Debian
contributors run sid and end-up in the same situation I ran into, where
you have a couple recommends that got removed and you wish to fix that.
That feature specifically reminds me of fsck commands where it allows
you to get back to a coherent system.
I do agree that having the option to specify the package would be very
nice, but I think removing the possibility to do that on all packages
would be a loss.
> Sadly I have no idea how to call it.
> I would have called it 'reinstall' as that is sort-of what the code
> does… but that should make it obvious that I shouldn't be naming things.
>
> (Famous last words: On the upside, the code for that shouldn't be hard)
Here is a couple of idea on the option naming:
--restore, I like this one as the option effectively restore the
packages in the state that they should be.
--ensure, same idea as behind restore.
--check or --verify, Not so sure about that one, it implies that no
action is done which is not the case.
> Sidenote: "configured policy" suggests there is something you can
> configure far above "install recommends". More like "install recommends
> if they are related to bluetooth, not related to gnome and included in
> the last stable release" – that would be a handy policy sometimes, but
> I don't see us getting there any time soon. And even then --fix-policy
> would need a few changes….
>
>
> Beste regards
>
> David Kalnischkies
--
Baptiste BEAUPLAT - lyknode
signature.asc
Description: OpenPGP digital signature
