Strange pkg_deinstall behaviour with pkgng

[Stefan Esser]

Am 29.07.2014 um 23:45 schrieb Baptiste Daroussin:
> On Tue, Jul 29, 2014 at 11:23:10PM +0200, Gyrd Thane Lange wrote:
>> General gripe about pkg(8): The command structure and options are
>> very similar to the previous pkg_tools but with enough changes in
>> options and behaviour that it trips up an unwary user. I feel
>> this is a POLA violation. It is almost like it is baiting the
>> user into making a mistake. Is is similar enough to the old tools
>> that the user think it is sufficient to just replace the hyphen
>> with a space (as in pkg-delete and pkg delete) but sometimes with
>> subtle changes in options or behaviour, most of them with no
>> clear rationale for the change.
>> 
>> I suppose that the superficial likeness was to make it more
>> familiar for existing users of pkg_tools, but since it is not
>> 100% compatible (would be better if it was) it would perhaps have
>> been better to make a clean break to remove preconceptions about
>> operations.
>> 
> making a clean break would have made the tool completly rejected,
> the fact we were quite closed did the trick to help the project
> moving to pkg.

Hi Bapt,

this is probably true and the pkg commands are similar enough for
interactive use, if you know pkg_ (and you'll spot unexpected
behaviour and adjust your usage if the output did not match your
expectations).

Don't get me wrong: I highly appreciate the effort and result of
creating the new pkg tools!

And I've been using them as soon as they were first available for
testing and have converted a few scripts to (also) support the
new pkg tools.


But I second Gyrd's position: Scripts will perform unexpected
actions without the user noticing that some intermediate step
was wrongly converted from pkg_ to pkg (or the semantics of the
pkg options changed when new features where added, changing the
previously compliant behaviour in a way not expected by the
author of the script).

We can try to keep portmaster and portupgrade, the bsdadmintools
and other script code, that relies on pkg consistent with the
evolving semantics of pkg options.


But there may be scripts we are not aware of or that we do not
have in the ports collection, which break in unexpected and hard
to fix ways.

IMHO the only viable solution is to be as compatible to the old
pkg_ tools as possible with reasonable effort.

When there are incompatibilities changes to the semantics of
an option (either because some option can not be implemented,
because it is obsolete, or because better semantics can be
provided), then a new option should be used for the new
semantics and the old option should either still be available
with the legacy result, or it should lead to an error abort
(and if you do not catch that in a script, that script is to
blame, not the new pkg tools).

In short:

- kept options should give very similar results

- new options may produce whatever they want

- useless options should not be re-used to provide some other
  useful result, but should instead lead to an error abort


And I'll repeat, that there is nothing wrong with pkg being
different from pkg_*. But care should be taken to prevent
non-interactive use of pkg from corrupting a system ...

Best regards, STefan