Re: Confirming PAUSE operating model safe harbor for Alt::* distributions

On 31 October 2017 at 15:54, David Golden <[email protected]> wrote:
> On Mon, Oct 30, 2017 at 3:11 AM, Aristotle Pagaltzis <[email protected]>
> wrote:
>>
>> >    - Per the "explicit user confirmation", I think an explicit opt-in
>> >      must be present, not merely checking for overwriting via hashing.
>>
>> I don=E2=80=99t think so, and think it=E2=80=99s fine to not require it.=
 But you didn=E2=80=99t
>> state a reason why you think that so I don=E2=80=99t know whether I disa=
gree
>> with you.
>
>
> Even if Peter's mechanism is in the spirit of the operating model, I woul=
d
> prefer the higher standard of "explicit confirmation" as the operating mo=
del
> call for.
>
> If you need a rationale -- practically speaking -- consider this scenario=
:
>
> 1. User without DBIC or DBIC::Boring installs some module Foo that depend=
s
> on DBIC::Boring; DBIC::Boring gets silently installed.
> 2. User installs some module Bar that depends on DBIC; because DBIC doesn=
't
> check for conflicts with DBIC::Boring, it silently overwrites it.
> 3. Foo is now broken.  User doesn't know why.
>
> Whereas if in #1, the user had to opt into DBIC::Boring, then they would =
be
> accepting the risk of future breakage from DBIC conflicts.

I would expect based on the stability goals of DBIC::Boring, that this
would mean the same kinds of breakages would be present for anyone who
simply upgraded from an older version of DBIC to a newer version of
DBIC

And subsequently, that module Foo is broken with new version of DBIC *anywa=
y*

Which means there is a logical problem in the ecosystem entirely
independent of the existence of DBIC::Boring

The only thing DBIC::Boring adds to this table is a situation where
Foo is not broken, other than "Have old DBIC"

Complaining that DBIC::Boring's own sub-ecosystem could become broken
by DBIC::Boring existing seems strange here, because the goal of this
safe-harbour provision is that DBIC::Boring can be permitted to exist
without interfering with DBIC's ecosystem.

And nothing in that example suggests DBIC::Boring interferes with
DBIC's ecosystem.

Only that DBIC's ecosystem may retroactively interfere with
DBIC::Boring's, which is an understood consequence of that design.


--=20
Kent

KENTNL - https://metacpan.org/author/KENTNL