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

[David Golden]

I asked on the private PAUSE admin list for other admins to add their
opinion.  A couple replied privately on that list or don't subscribe to
CPAN workers. I have their permission to repost their comments here:

>From Steffen Mueller:
> I just read the cpan workers thread. My stance on this was very well
> articulated by David's message at
>
> https://www.nntp.perl.org/group/perl.cpan.workers/2017/10/msg1581.html
>
> Maybe I feel a tad more strongly. I think overwriting other
> distribution's files on the file system is a very heavy-handed solution
> to a more general problem (multi-versioning where not all versions are
> controlled by the same author, here with the limitation of only allowing
> one at a time). Next to all the corner cases already pointed out, I
> think there will be lots more that will particularly bite the less
> experienced users and sysadmins. The cost here outweighs the benefit by
> a mile.
>
> As PAUSE admins with a published operating model, I think we should be
> clear in that with explicit and specific user consent, this behavior is
> technically acceptable, but from a point of view of a group of people
> who've seen a lot of bad solutions, we should nonetheless discourage
> that choice of solution.
>
> I'm not currently subscribed to cpan workers and don't have an nntp
> client handy, so thus here. But you're all more than welcome to quote me
> with the above.

>From Ron Savage:
> From David's post (copied into here, hence wrap) with replies in situ:
> >My personal thoughts:
> > - The reason for the safe harbor clause in the first place was to allow
> > this sort of thing while putting appropriate protections in place for
end
> > users -- so I think the intent is clearly protected by the safe harbor
and
> > questions should focus only on mechanisms and transparency.
>
> Agreed.
>
> > - Per the "explicit user confirmation", I think an explicit opt-in must
> > be present, not merely checking for overwriting via hashing.  If
prompting
> > during Makefile.PL, I would prefer the default to be "no", but I don't
>
> Agreed.
>
> > think the safe harbor is violated if the default is "yes" (people who
> > auto-accept prompts get what they deserve).
>
> > - I would prefer checking for the presence of an environment variable
> > over prompting as that similarly indicates explicit confirmation and is
> > kinder to many poor users who auto-accept prompts -- or whose cpan
client
> > does so on their behalf.
>
> Agreed.
>
> > - I'd be happy to see a convention established checking for a particular
> > environment variable like "PERL_ALLOW_ALT_MODULES=1" that could apply
> > across many Alt-style modules.  A Makefile.PL prompt could default to
"yes"
> > if the environment variable is true..
>
> Agreed.
>
> > - I have no objection to "DBIx::Class::Boring" as a name.  I don't think
> > we should mandate a convention of "Alt::*".
>
> It would help of the Alt name chosen clearly indicated the target name,
> to make searching MetaCPAN less painful.



On Tue, Oct 31, 2017 at 9:33 AM, David Golden  wrote:

> Let me be very clear that, to me, the issue at stake is about two (or
> more) distributions "fighting" over a particular path on the filesystem.
> My position -- consistent with that of the Operating Model -- is that this
> is not acceptable unless a user explicitly opts into such a situation in
> some way.  Period.
>
> There are other alt-module mechanisms that don't have that problem.
>
> Consider a Bar and Alt::Bar that install into their usual places in the
> filesystem.  Imagine a pragma "shadowing.pm" such that "use shadowing
> 'Bar' => 'Alt::Bar'" installs an @INC hook to replace the "Bar" prefix with
> "Alt::Bar".  I'd have no problem with such a runtime effect because Bar is
> still usable in it's ordinary form by anything that doesn't invoke the
> shadowing.
>
> I'd even be OK with a deep dependency invoking the shadowing -- a deep
> dependency could do anything, after all, and users are responsible for
> their full dependency tree (even if, in practice, people don't pay
> attention).
>
> From there, it's not hard to imagine that loading Alt::Bar *itself* does
> the shadowing, so that any subsequent loads of Bar::* are redirected to
> Alt::Bar::*.  As Bar is still usable independently, that doesn't run into
> the Operating Model prohibition.
>
> To justify why, recall that the prohibition is stated as "*installing* an
> indexed distribution.. should not change post-install module loading for
> any package that is not indexed to that distribution" [emphasis mine].
> Merely *installing* Alt::Bar does not change the loading of Bar.  The *use*
> of Alt::Bar does, but the Operating Model doesn't speak to that (nor do I
> think it should).
>
> There are other runtime mechanisms one could imagine along these lines.
> E.g. loading Alt::Bar could set $INC{"Bar.pm"}.  The design of such systems
> is left as an exercise for the reader.  :-)
>
> I'm curious what other PAUSE admins 

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

[H.Merijn Brand]

On Wed, 01 Nov 2017 00:44:12 +0100, Andreas Koenig
 wrote:

> My reasoning tries to base on previous art first, the letter of the
> Pause Operating Model (POM) second, and the intent of the POM third.
> Since the intent can only be guessed, we would hope that we do not
> need to resort to that. But then there is a fourth thing: reasoning what
> we as a community *need* to achieve.
> 
> Previous art
> 
> One distribution comes to mind that asks the user whether he wants to
> install a secondary namespace:
> 
>  : Installing Data::Dump::Streamer
>  : 
>  : I can install a shortcut so you can use the package 'DDS'
>  : as though it was 'Data::Dump::Streamer'. This is handy for oneliners.
>  : *Note* that if you select 'no' below and you already
>  : have it installed then it will be removed.
>  : 
>  : Would you like me to install the shortcut? (yes/no) [no ]
> 
> So it is a long established practice, that modules may ask for
> permission to be installed under a different name. I haven't ever heard
> complaints about that.

Yes, I also see this as common practice

I only saw these as top-level "namespace", and none with ::

I have CSV.pm available for Text::CSV_XS adding Data::Peek, but the
build does not offer it as shortcut. You have to install it yourself
from the git checkout (it is not included in the release tarball)
https://github.com/Tux/Text-CSV_XS/blob/master/sandbox/CSV.pm

I have DP.pm for Data::Peek, just like DDS for Data::Dump::Streamer.
https://github.com/Tux/Data-Peek/blob/master/Makefile.PL#L35

> Letter of the POM
> 
> The following citation is taken directly from the POM:
> 
>  : * Installing your module(s) should not result in changes to
>  :   someone else's modules that might already be installed,
>  :   either by changing them or removing them.

Hmm, that would mean that DDS and DP should *ONLY* install if DP.pm or
DDS.pm does not exist or exists as the intended wrapper in a previous
version. (/me takes action ...)

>  : * The one exception to the above is where that's the whole raison d'être
>  :   of your module.
>  :   In that case it should be clearly documented as such,
>  :   and the installation process should get explicit user confirmation
>  :   that they wish to proceed with this.
>  :   The documentation and name of your module should be respectful.
> 
> I understand the first paragraph as: if your module is A you must not
> change or remove module B. The second paragraph makes this mandate
> relative: if your module is A you must not change or remove module B
> *under the hood*. But everything's fair if you predeclare. If all you
> want to achieve is changing B, then get explicit permission from the end
> user and do it.
> 
> Intent of the POM
> 
> This is my personal reading of the two written paragraphs I cited above,
> so probably the intent: Perl5 is really bad at dealing with two
> implementations on the same namespace, so if a precious namespace has
> competing interpretations and people cannot come up with a clever way of
> separating code into alternative namespaces, we should not get in the
> way as long as developer and end user agree on what they want to
> achieve.
> 
> What *we* must achieve
> 
> Foremost debuggability: if things go wrong we should be able to find out
> which parties were involved and how. What was intended, what happened,
> which contract or perceived contract was broken. And we need to be able
> to identify a way forward. We need a way to go from A to B and from B to
> A. When B has been overwritten, we need a way to find out whether the
> user has agreed to overwriting B.
> 
> The overwriter is kindly asked to provide clue about what's going on and
> avoid obscuring things. For example, how will cpantesters reports look
> like? They should of course be attributed to the overwriting module, not
> to the overwritten one.
> 
> After installation: in the past we could pretty much rely on paths in
> the filesystem and version numbers. This stops working when a distro
> could overwrite a file with code that declares the same version number.
> But I can imagine plenty of ways to prevent that sort of confusion. Some
> will *just work*, so we probably need not explain the nitty gritty
> details in the POM how this is achieved best. People will have to find
> that out on their own.
> 
> And besides debuggability what we really need to achieve is that such
> approaches about dealing with conflicting goals find a way of
> coexistence. What we cannot allow is that module A's whole raison d'être
> is modifying B and B's whole raison d'être is modifying A. If such a
> circular reference happens, it's probably time to reboot CPAN.
> 
> Yes, it should not be done lightly. It may cause major havoc if done
> wrongly. There are probably plenty of pitfalls before mutually each
> other overwriting CPAN modules.
> 
>  [...]  
> 
>   > Let me be very clear that, to me, the issue at stake is about two (or
>   > more) 

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

[Andreas Koenig]

My reasoning tries to base on previous art first, the letter of the
Pause Operating Model (POM) second, and the intent of the POM third.
Since the intent can only be guessed, we would hope that we do not
need to resort to that. But then there is a fourth thing: reasoning what
we as a community *need* to achieve.

Previous art

One distribution comes to mind that asks the user whether he wants to
install a secondary namespace:

 : Installing Data::Dump::Streamer
 : 
 : I can install a shortcut so you can use the package 'DDS'
 : as though it was 'Data::Dump::Streamer'. This is handy for oneliners.
 : *Note* that if you select 'no' below and you already
 : have it installed then it will be removed.
 : 
 : Would you like me to install the shortcut? (yes/no) [no ]

So it is a long established practice, that modules may ask for
permission to be installed under a different name. I haven't ever heard
complaints about that.

Letter of the POM

The following citation is taken directly from the POM:

 : * Installing your module(s) should not result in changes to
 :   someone else's modules that might already be installed,
 :   either by changing them or removing them.
 : * The one exception to the above is where that's the whole raison d'être
 :   of your module.
 :   In that case it should be clearly documented as such,
 :   and the installation process should get explicit user confirmation
 :   that they wish to proceed with this.
 :   The documentation and name of your module should be respectful.

I understand the first paragraph as: if your module is A you must not
change or remove module B. The second paragraph makes this mandate
relative: if your module is A you must not change or remove module B
*under the hood*. But everything's fair if you predeclare. If all you
want to achieve is changing B, then get explicit permission from the end
user and do it.

Intent of the POM

This is my personal reading of the two written paragraphs I cited above,
so probably the intent: Perl5 is really bad at dealing with two
implementations on the same namespace, so if a precious namespace has
competing interpretations and people cannot come up with a clever way of
separating code into alternative namespaces, we should not get in the
way as long as developer and end user agree on what they want to
achieve.

What *we* must achieve

Foremost debuggability: if things go wrong we should be able to find out
which parties were involved and how. What was intended, what happened,
which contract or perceived contract was broken. And we need to be able
to identify a way forward. We need a way to go from A to B and from B to
A. When B has been overwritten, we need a way to find out whether the
user has agreed to overwriting B.

The overwriter is kindly asked to provide clue about what's going on and
avoid obscuring things. For example, how will cpantesters reports look
like? They should of course be attributed to the overwriting module, not
to the overwritten one.

After installation: in the past we could pretty much rely on paths in
the filesystem and version numbers. This stops working when a distro
could overwrite a file with code that declares the same version number.
But I can imagine plenty of ways to prevent that sort of confusion. Some
will *just work*, so we probably need not explain the nitty gritty
details in the POM how this is achieved best. People will have to find
that out on their own.

And besides debuggability what we really need to achieve is that such
approaches about dealing with conflicting goals find a way of
coexistence. What we cannot allow is that module A's whole raison d'être
is modifying B and B's whole raison d'être is modifying A. If such a
circular reference happens, it's probably time to reboot CPAN.

Yes, it should not be done lightly. It may cause major havoc if done
wrongly. There are probably plenty of pitfalls before mutually each
other overwriting CPAN modules.

> On Tue, 31 Oct 2017 09:33:38 -0400, David Golden  said:

  > Let me be very clear that, to me, the issue at stake is about two (or
  > more) distributions "fighting" over a particular path on the
  > filesystem. My position -- consistent with that of the Operating Model
  > -- is that this is not acceptable unless a user explicitly opts into
  > such a situation in some way. Period.

Agreed. Onus of proof is with the overwriter. Whether the agreement must
be renewed on every installation is subject to their agreement.
Overwriter is kindly requested to be clear about the intent and how to
opt out later.

  > [...]

  > To justify why, recall that the prohibition is stated as "*installing*
  > an indexed distribution.. should not change post-install module
  > loading for any package that is not indexed to that distribution"
  > [emphasis mine]. Merely *installing* Alt::Bar does not change the
  > loading of Bar. The *use* of Alt::Bar does, but the Operating Model
  > doesn't speak to that (nor do I think it should).

I 

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

[Kent Fredric]

On 31 October 2017 at 15:54, David Golden  wrote:
> On Mon, Oct 30, 2017 at 3:11 AM, Aristotle Pagaltzis 
> wrote:
>>
>> >- Per the "explicit user confirmation", I think an explicit opt-in
>> >  must be present, not merely checking for overwriting via hashing.
>>
>> I don’t think so, and think it’s fine to not require it. But you didn’t
>> state a reason why you think that so I don’t know whether I disagree
>> with you.
>
>
> Even if Peter's mechanism is in the spirit of the operating model, I would
> prefer the higher standard of "explicit confirmation" as the operating model
> call for.
>
> If you need a rationale -- practically speaking -- consider this scenario:
>
> 1. User without DBIC or DBIC::Boring installs some module Foo that depends
> 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 *anyway*

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.


-- 
Kent

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

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

[Aristotle Pagaltzis]

* David Golden  [2017-10-26 14:58]:
> What do we think about this? Do we feel it falls under the 'safe
> harbor' exception?

As far as I can see, the mechanism described by Peter does not permit
scenarios in which a user unwittingly gets their Perl installation
screwed over by DBIx::Class::Boring. As such, it seems to me that the
mechanism follows the spirit of the principles, and therefore should
clearly fall under the safe-harbour clause in question.

> My personal thoughts:
>
>- The reason for the safe harbor clause in the first place was to
>  allow this sort of thing while putting appropriate protections in
>  place for end users -- so I think the intent is clearly protected
>  by the safe harbor and questions should focus only on mechanisms
>  and transparency.

Agreed.

>- Per the "explicit user confirmation", I think an explicit opt-in
>  must be present, not merely checking for overwriting via hashing.

I don’t think so, and think it’s fine to not require it. But you didn’t
state a reason why you think that so I don’t know whether I disagree
with you.

In particular, requiring an opt-in even in presence of a hash match
interacts badly with the fact that the actual codebase in the fork will
be staying in the DBIx::Class namespace for at least a very long time,
because it means that an opt-in is required not only for switching to
the fork, but also for all upgrades *after* following the fork. Such
a requirement would therefore mean that users who intend to stay on
the DBIx::Class::Boring fork, or who use a downstream project that has
chosen the DBIx::Class::Boring fork, will forever be needing to shim the
setting of this environment variable into their toolchain or deploy
machinery.

OTOH, I believe upgrading users of a forked module from a pre-fork
version to the post-fork codebase is fine *so long as* the fork has
a sufficiently strong backcompat commitment to pre-fork versions. And
as far as that applies to DBIx::Class::Boring, the most neutral way
I can express myself is that the entire situation came to a head because
Peter’s commitment to backcompat has been perceived as *too* overriding.

These are my reasons to believe that explicit opt-in under pure-upgrade
situations (as opposed to switching an installation over from the other
fork) is neither necessary nor reasonable under the mechanism described
in the proposal you quoted.

>  If prompting during Makefile.PL, I would prefer the default to be
>  "no", but I don't think the safe harbor is violated if the
>  default is "yes" (people who auto-accept prompts get what they
>  deserve).

The proposal you quoted says that the installation will *abort*, without
even a prompt, unless explicit opt-in via environment variable is given.
Therefore this requirement is fulfilled in spades.

>- I would prefer checking for the presence of an environment
>  variable over prompting as that similarly indicates explicit
>  confirmation and is kinder to many poor users who auto-accept
>  prompts -- or whose cpan client does so on their behalf.

(See right above.)

>- I'd be happy to see a convention established checking for
>  a particular environment variable like "PERL_ALLOW_ALT_MODULES=1"
>  that could apply across many Alt-style modules. A Makefile.PL
>  prompt could default to "yes" if the environment variable is
>  true..

Generally, yes. But I have to agree with Chad on this point: an opt-in
should be specific to particular modules, and not limit the user to
expressing a blanket “I accept any Alt:: that might be listed anywhere
in my dep chain”. In fact I raised this exact issue a long time ago:
https://github.com/ingydotnet/alt-pm/issues/3

It’s fine for there to be a convention for such opt-ins. It’s possibly
even a good idea (if it comes up in enough different cases in practice
to matter).

Peter’s proposal in particular is already sane on that specific front.

>- I have no objection to "DBIx::Class::Boring" as a name. I don't
>  think we should mandate a convention of "Alt::*".

Agree. I believe that conveying intent through the name is imperative
only when the protection of users at install time is too weak – as it
has been in Ingy’s conception of the Alt:: concept.

Regards,
-- 
Aristotle Pagaltzis // 

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

[Todd Rinaldo]

> On Oct 26, 2017, at 11:04 PM, Salve J Nilsen  wrote:
> 
> David Golden said:
>> On Thu, Oct 26, 2017 at 11:29 AM, Chad Granum  wrote:
>> 
>>> I have a small objection to putting an alt module in a namespace other
>>> than alt: It is less obvious. If I see Alt::Thing I will simply know it
>>> will replace Thing.
>> 
>> Consider, too, if someone else wants to another alternative Thing.
>> Alt::Thing2 -- is that a second Alt::Thing?  Or an alternative of Thing2?
>> 
>> Possibly namespacing like Thing::Alt::Boring would then allow
>> Thing::Alt::Spiffy, etc.  But I don't want to have explicit rules about
>> this.  I think intent is more important.
> 
> Would adding a field to the META spec about API conformance solve some this?
> 
> api_conforms_to:
>   module: CPAN::Thing
>   version: 2.61
> 

As a packager, that would certainly make it easier. We've run into 2 cpan 
modules using the same file in the past and had to sort it out. This sort of 
information would be a very helpful thing we could check.

Todd



smime.p7s
Description: S/MIME cryptographic signature

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

[Salve J Nilsen]

David Golden said:

On Thu, Oct 26, 2017 at 11:29 AM, Chad Granum  wrote:


I have a small objection to putting an alt module in a namespace other
than alt: It is less obvious. If I see Alt::Thing I will simply know it
will replace Thing.


Consider, too, if someone else wants to another alternative Thing.
Alt::Thing2 -- is that a second Alt::Thing?  Or an alternative of Thing2?

Possibly namespacing like Thing::Alt::Boring would then allow
Thing::Alt::Spiffy, etc.  But I don't want to have explicit rules about
this.  I think intent is more important.


Would adding a field to the META spec about API conformance solve some this?

api_conforms_to:
   module: CPAN::Thing
   version: 2.61


- Salve (possibly opening a can of worms here)

--
#!/usr/bin/env perl
sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print# Salve Joshua Nilsen
getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':50,$'.#
'3!=0"59,6!`%%P\0!1)46%!F.Q`%01,`'."\n"));eval "&{'@_'}";  __END__ is near! :)

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

[Chad Granum]

I think ::Alt:: should be present in the name, though I do not care where.

Why:

 * Conveys intent better
 * Probably easier for indexes to avoid having the alt-module listed as the
newest version of the non-alt module
 * Cpan-testers can filter based on it.

Essentially everything boils down to making tooling and expectations easier
if one of Alt::/::Alt::/::Alt are required in the namespace.

I do not like the idea of making everyone have to go out of there way to
look for documentation that explicitly states that the module is
alt/non-alt. I do not trust most alt authors to make it clear in docs that
their module is alt (ribaushi is one of very few people who I do trust to
get this all correct).

Enforcing that 'Alt' be present somewhere feels like a win to me in
reducing cognitive overhead of users, and making some tooling easier.

-Chad

On Thu, Oct 26, 2017 at 9:31 AM, David Golden  wrote:

> On Thu, Oct 26, 2017 at 11:29 AM, Chad Granum  wrote:
>
>> I have a small objection to putting an alt module in a namespace other
>> than alt: It is less obvious. If I see Alt::Thing I will simply know it
>> will replace Thing.
>>
>
>
> Consider, too, if someone else wants to another alternative Thing.
> Alt::Thing2 -- is that a second Alt::Thing?  Or an alternative of Thing2?
>
> Possibly namespacing like Thing::Alt::Boring would then allow
> Thing::Alt::Spiffy, etc.  But I don't want to have explicit rules about
> this.  I think intent is more important.
>
> David
>

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

[David Golden]

On Thu, Oct 26, 2017 at 11:29 AM, Chad Granum  wrote:

> I have a small objection to putting an alt module in a namespace other
> than alt: It is less obvious. If I see Alt::Thing I will simply know it
> will replace Thing.
>


Consider, too, if someone else wants to another alternative Thing.
Alt::Thing2 -- is that a second Alt::Thing?  Or an alternative of Thing2?

Possibly namespacing like Thing::Alt::Boring would then allow
Thing::Alt::Spiffy, etc.  But I don't want to have explicit rules about
this.  I think intent is more important.

David

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

[Chad Granum]

I think alt modules are fine.

I am fine with an env-var solution, BUT I am now ok with a single env var
that allows any alt module in. I would recommend either a standard such as
PERL_ALLOW_ALT_[MODULE_NAME], or PERL_ALLOW_ALT="Alt::One,Alt::2". I doubd
anyone wants to allow arbitrary alt modules as opposed to specific alt
modules.

I have a small objection to putting an alt module in a namespace other than
alt: It is less obvious. If I see Alt::Thing I will simply know it will
replace Thing. The same is not obvious for the ::Boring postfix. People
make ::Tiny, ::Simple (and in my case ::LessClever) namespaces all the
time, which emulate the behavior of an existing module, but do not actually
replace it. This is not a killer issue for me, just a preference. I also
think the Alt:: namespace will make things easier on cpan-testers who do
not want an accidental override of the default implementation of a
namespace.

Riba mentioned making it NOT prompt for upgrading from versions older
than 0.082840, and not prompting if the alt:: is already installed. I am
perfectly fine with skipping the prompt if an older version of the Alt:: is
already installed, that makes complete sense to me. I am torn on the lack
of prompt when upgrading from a version before the fork. I think the
benefit of not needing to confirm the install DOES NOT outweigh the
importance of making sure people know that they are getting an Alt::
module, possibly by accident.

-Chad

On Thu, Oct 26, 2017 at 5:53 AM, David Golden  wrote:

> Neil, Andreas and I got an email request from Peter Rabbitson to confirm
> his reading of the new PAUSE operating model.  I see no reason for this
> discussion to be secret so I'm emailing cpan-workers for opinions, as
> suggested in the operating model document.  While PAUSE admins will make a
> final decision on this matter, I welcome non-admin opinions about the
> situation.
>
> Peter wants to know if his intended approach for alternative distributions
> falls under a "safe harbor" clause of the operating model.
>
> Specifically, the operating model says
> 
> :
>
> "As a general rule, installing an indexed distribution (i.e. tarball, zip
> file), should not change post-install module loading for any package that
> is not indexed to that distribution... Installing your module(s) should not
> result in changes to someone else's modules that might already be
> installed, either by changing them or removing them... The one exception to
> the above is where that's the whole raison d'être of your module. In that
> case it should be clearly documented as such, and the installation process
> should get explicit user confirmation that they wish to proceed with this.
> The documentation and name of your module should be respectful."
>
> Peter's desire is to release Alt::* style modules whose raison d'être is
> to provide a drop in replacement:
>
> As stated on the mailing list many moons ago, soon after the new
>> DBIx::Class management gets on with development I intend to ship my own
>> versions of these modules under a "fail-safe Alt::-like system". The
>> indexed namespace will of course have a different name (
>> DBIx::Class::Boring as working title ), but will install over preexisting
>> DBIx::Class* modules IFF it recognizes what it is about to overwrite as
>> being the contents of DBIx::Class 0.082840 or earlier ( I will simply hash
>> every file ever shipped by myself, and compare against this whitelist of
>> what is safe to overwrite ). Failing that the installation will abort and a
>> user will have to set a specific environment variable in order to proceed
>> further. I intend to trial this with SQL::Abstract::Boring first. Given the
>> available ecosystem installers, this is the closest thing I can come up
>> with while leaving a choice to the userbase.
>>
>
> What do we think about this?  Do we feel it falls under the 'safe harbor'
> exception?  If not, what would Peter need to do to be protected by it?
>
> My personal thoughts:
>
>
>- The reason for the safe harbor clause in the first place was to
>allow this sort of thing while putting appropriate protections in place for
>end users -- so I think the intent is clearly protected by the safe harbor
>and questions should focus only on mechanisms and transparency.
>- Per the "explicit user confirmation", I think an explicit opt-in
>must be present, not merely checking for overwriting via hashing.  If
>prompting during Makefile.PL, I would prefer the default to be "no", but I
>don't think the safe harbor is violated if the default is "yes" (people who
>auto-accept prompts get what they deserve).
>- I would prefer checking for the presence of an environment variable
>over prompting as that similarly indicates explicit confirmation and is
>kinder to many poor users who