Bug #108908 for Net-DNS: Installing recent version gets shadowed by old version

Fri Nov 13 22:48:52 2015 KENTNL [...] cpan.org - Ticket created

Subject:

Installing recent version gets shadowed by old version

Somewhere between 0.83 and the current version, it appears the location Net::DNS installs to gets changed.

On version 0.83, it installs to "${site}/${arch}/<>" but on 1.03 it installs to "${site}/<>"

Which is unfortunate, because the former shadows the later, so even after upgrading, the upgraded version is not seen in @INC, only the older version.

Fortunately, there is a cure.

Here's some code by HAARG++ https://metacpan.org/source/HAARG/Devel-GlobalDestruction-0.13/Makefile.PL#L75-88

That example code checks for an older version of itself, and if a version older than a certain age is found, it appends code to make to request the removal of the ${arch} version so that it doesn't get shadowed.

This is not a blanket "find and delete", but it only deletes the problem file from the arch directory corresponding to the install target.

Tue Dec 08 16:53:22 2015 rwfranks [...] acm.org - Correspondence added

From:

rwfranks [...] acm.org

On Fri Nov 13 22:48:52 2015, KENTNL wrote: Show quoted text

> Somewhere between 0.83 and the current version, it appears the > location > Net::DNS installs to gets changed. > > On version 0.83, it installs to "${site}/${arch}/<>" but on 1.03 it > installs to > "${site}/<>" > > Which is unfortunate, because the former shadows the later, so even > after > upgrading, the upgraded version is not seen in @INC, only the older > version.

This is really a library management tool issue which arises because the compiled XS code has been removed in 1.00+. This fell into disuse long ago, but was retained until the principal version number changed, minimising the impact of the problem you describe. It is not unreasonable to expect to perform a clean install when passing 1.00 Show quoted text

> > Fortunately, there is a cure. > > Here's some code by HAARG++ > https://metacpan.org/source/HAARG/Devel-GlobalDestruction- > 0.13/Makefile.PL#L75-88 > > That example code checks for an older version of itself, and if a > version older > than a certain age is found, it appends code to make to request the > removal of > the ${arch} version so that it doesn't get shadowed. > > This is not a blanket "find and delete", but it only deletes the > problem file > from the arch directory corresponding to the install target.

Attempting to compete with "proper" installation tools risks leaving a trail of wrecked libraries or other unintended consequences. Better not to go there.

Tue Dec 08 16:53:23 2015 The RT System itself - Status changed from 'new' to 'open'

Tue Dec 08 17:06:45 2015 KENTNL [...] cpan.org - Correspondence added

On 2015-12-09 10:53:22, rwfranks@acm.org wrote:
> It is not unreasonable to expect to perform a clean install when
> passing 1.00

I personally find "You can't upgrade, you must install a fresh perl and start over" very much within the grounds of unreasonable.

Reinstalling *thousands* of modules just because Net::DNS released an update is very much non-great.

I'd imagine anybody presented with the choice between "Just delete this file" and "Reinstall perl and >1000 modules" will choose the former.

> Attempting to compete with "proper" installation tools risks leaving a
> trail of wrecked libraries or other unintended consequences. Better
> not to go there.

It doesn't exactly "compete" with "proper" installation tools.

It literally just adds a rule to the makefile that nukes an older version from $TARGET_DIR

"Proper" installation tools are more likely to have a managed system where $TARGET_DIR is an empty directory which is then applied to the final system using file-management techniques, as well as having shadow-removal an inherent feature of their toolkit. ( Removing previous generation cleanly removes the unwanted file )

And its worth noting that this technique in use by Devel::GlobalDestruction very much should be taken under consideration, given the maintainers of that module are part of our toolchain hackers, and given that module is used by Moose and Moo, and given those Modules are presently replicated to *many* Linux distros with "proper" installer tools, I'd imagine if it was a problem there we'd have found it already.

Of course, I'm all for measuring potential risks and making careful steps so that we don't make a bigger mess, but we have to know specifically what problems you're afraid will happen and then work out if they're really a problem or not.

Mon Dec 14 16:46:13 2015 ether [...] cpan.org - Requestor ETHER added

Thu Dec 17 11:01:06 2015 rwfranks [...] acm.org - Correspondence added

From:

rwfranks [...] acm.org

On Tue Dec 08 17:06:45 2015, KENTNL wrote: Show quoted text

> On 2015-12-09 10:53:22, rwfranks@acm.org wrote:

> > It is not unreasonable to expect to perform a clean install when > > passing 1.00

> > I personally find "You can't upgrade, you must install a fresh perl > and start > over" very much within the grounds of unreasonable. > > Reinstalling *thousands* of modules just because Net::DNS released an > update is > very much non-great. > > I'd imagine anybody presented with the choice between "Just delete > this file" > and "Reinstall perl and >1000 modules" will choose the former. >

If "just delete this file" is what you need to do, just do that. However, that is an entirely different proposition from possibly inflicting automated collateral damage on thousands of unsuspecting users. Show quoted text

> It doesn't exactly "compete" with "proper" installation tools. > > It literally just adds a rule to the makefile that nukes an older > version from $TARGET_DIR

Many times in my (long) career I have heard "but it just ..." which heralded some entirely avoidable catastrophe. Show quoted text

> Of course, I'm all for measuring potential risks and making careful > steps so > that we don't make a bigger mess, but we have to know specifically > what > problems you're afraid will happen and then work out if they're really > a > problem or not.

There are too many different tools and upgrade scenarios out there to guess what the possible problems may be. Neither am I keen to jump into that particular snake pit. There is, and needs to be, a clear separation of concerns between developer and installer. The demarcation point is widely recognised to be the CPAN library. The developer's mission is to produce a library component in the shape required for a clean install to work and pass all the installation tests. The toolchain, with possible user intervention, takes responsibility for carrying that recipe into effect.

Thu Dec 17 11:27:29 2015 rt-cpan [...] trout.me.uk - Correspondence added

On Thu Dec 17 11:01:06 2015, rwfranks@acm.org wrote: Show quoted text

> The toolchain, with possible user intervention, takes responsibility > for carrying that recipe into effect.

The toolchain has an option for this - UNINST=1 / --uninst=1 - but for various reasons many users choose not to set this. What I would suggest is to detect that the currently installed Net::DNS is in an arch dir, and if UNINST=1 hasn't been passed, have Makefile.PL die with an informative error message that requires the user either to pass UNINST=1 or to promise that they'll fix it themselves by setting e.g. NET_DNS_INSTALL_ANYWAY=1 (name made up on the spot, no particular recommendation implied) That will mean that clean installs will work exactly as they currently do, but a user about to descend into madness unexpectedly will get a chance to decide what they want to happen. If you're willing to accept a patch for this but don't feel it's something you want to write yourself, I'm sure we could find a volunteer to do so.

Thu Dec 17 20:45:53 2015 ribasushi [...] leporine.io - Cc RIBASUSHI added

Wed Dec 30 12:58:03 2015 rwfranks [...] acm.org - Correspondence added

From:

rwfranks [...] acm.org

On Thu Dec 17 11:27:29 2015, MSTROUT wrote: Show quoted text

> What I would suggest is to detect that the currently installed > Net::DNS is in an arch dir, and if UNINST=1 hasn't been passed, have > Makefile.PL die with an informative error message that requires the > user either to pass UNINST=1 or to promise that they'll fix it > themselves by setting e.g. NET_DNS_INSTALL_ANYWAY=1 (name made up on > the spot, no particular recommendation implied)

Adding a prominent warning message seems a reasonable suggestion. Show quoted text

> That will mean that clean installs will work exactly as they currently > do, but a user about to descend into madness unexpectedly will get a > chance to decide what they want to happen.

As they should Show quoted text

> > If you're willing to accept a patch for this but don't feel it's > something you want to write yourself, I'm sure we could find a > volunteer to do so.

No real need to abort the installation process in this situation. Deleting the arch directory can be done afterwards.

Wed Dec 30 16:31:43 2015 KENTNL [...] cpan.org - Correspondence added

On 2015-12-31 06:58:03, rwfranks@acm.org wrote:
> No real need to abort the installation process in this situation.
> Deleting the arch directory can be done afterwards.

If somebody depends on a minimum version of Net::DNS that is larger than the version which this transition occurred at, then everything in the subsequent dependency graph can be expected to fail in unpredictable ways which the people who declare those dependencies cannot solve.

Which means you're not going to know about the problem, and the warning will get lost in the river of output, and your package that needs Net::DNS will fail, and you'll have to dig around diagnosing why.

Which means the effort to produce a warning in such a case achieved nothing.

Thu Dec 31 08:05:30 2015 rwfranks [...] acm.org - Correspondence added

From:

rwfranks [...] acm.org

On Wed Dec 30 16:31:43 2015, KENTNL wrote: Show quoted text

> On 2015-12-31 06:58:03, rwfranks@acm.org wrote:

> > No real need to abort the installation process in this situation. > > Deleting the arch directory can be done afterwards.

> > If somebody depends on a minimum version of Net::DNS that is larger > than the > version which this transition occurred at, then everything in the > subsequent > dependency graph can be expected to fail in unpredictable ways which > the people > who declare those dependencies cannot solve. > > Which means you're not going to know about the problem, and the > warning will > get lost in the river of output, and your package that needs Net::DNS > will > fail, and you'll have to dig around diagnosing why. > > Which means the effort to produce a warning in such a case achieved > nothing.

So you are arguing for a fatal error at perl Makefile.PL time?

Sun Jan 24 07:45:26 2016 KENTNL [...] cpan.org - Correspondence added

On 2016-01-01 02:05:30, rwfranks@acm.org wrote:
>
> So you are arguing for a fatal error at perl Makefile.PL time?

Yes. Given Net::DNS is not going correct the situation automatically, and installing Net::DNS will mislead any CPAN client about what has transpired such that future breakages are guaranteed, the only right thing to do is to fail in advance of that problem happening.

That is, treat a system with an existing old version of Net::DNS as a "misconfigured" and "Unable to support this version of Net::DNS" until that problem is remedied by other means.

Fri Jan 29 15:05:25 2016 rwfranks [...] acm.org - Correspondence added

From:

rwfranks [...] acm.org

On Sun Jan 24 07:45:26 2016, KENTNL wrote: Show quoted text

> On 2016-01-01 02:05:30, rwfranks@acm.org wrote:

> > > > So you are arguing for a fatal error at perl Makefile.PL time?

> > Yes. Given Net::DNS is not going correct the situation automatically, > and > installing Net::DNS will mislead any CPAN client about what has > transpired such > that future breakages are guaranteed, the only right thing to do is to > fail in > advance of that problem happening. > > That is, treat a system with an existing old version of Net::DNS as a > "misconfigured" and "Unable to support this version of Net::DNS" until > that > problem is remedied by other means.

Although the motivation is different, the situation is similar to the behaviour when using the PREREQ_FATAL option. The ExtUtils::MakeMaker documentation says: It is extremely rare to have to use "PREREQ_FATAL". Its use by module authors is _strongly_discouraged_ and should never be used lightly. I find myself strongly discouraged. A prominent message has been added to Makefile.PL followed by a long sleep to ensure that it remains on screen long enough to be noticed.

Fri Jan 29 22:58:59 2016 KENTNL [...] cpan.org - Correspondence added

Its not really related to PREREQ_FATAL for a lot of reasons.

1. You can't depend on yourself here, so you can't demand that a CPAN client does *not* have an older version of yourself. ( Actually, that might be viable, I just haven't heard of it being done before and the support is likely very scant )

2. Unlike PREREQS, you're not providing *any* mechanism by which the CPAN client can resolve it on its own.

I see it more like "Your system can't support this because of a problem outside the scope of a CPAN Client", which is used extensively in everything that uses XS or external dependencies.

For instance, if your library requires a binary in $PATH that can't be provided by CPAN, then an "exit: N/A" from Makefile.PL is appropriate.

If for instance, your library requires a linkable .so in the library paths, or a .h file in @INC paths, an early "no, I cannot actually continue" is appropriate from Makefile.PL ( signalled by an early exit

So here, you very much have the same "this is a problem that will happen when you use a CPAN client and your CPAN client will do nothing to help you" problem space.

Similarly, your approach of "just warn and then continue" with the bin/lib example cases would map to the tool installing anyway regardless of the lack of a `bin/` , and then later failing in confusing ways when something tried to use your module and it didn't work.

And in the lib case, you'd be installing the pure-perl parts without any of the XS parts, and then again, the module would break when somebody attempted to use it, without it being obvious why, and you'd be a long way from the problem when that happened.

Similarly, "I'll install, but I won't actually be there and usable after I'm installed for ways that a CPAN client can't help with, and I refuse to help with in any way" is essentially a violation of the CPAN dependency contract.

If your module *cannot* be used, then it *should not* be able to be installed.

Fri Jan 29 23:11:14 2016 KENTNL [...] cpan.org - Correspondence added

On 2016-01-30 09:05:25, rwfranks@acm.org wrote:
>
> A prominent message has been added to Makefile.PL followed by a long
> sleep to ensure that it remains on screen long enough to be noticed.

^ and this part may on its own have no effect, because when you're installing a lot of dependencies ( where one is an upgrade trigger ), you're likely to not see anything, regardless of how long you set the wait for for several reasons.

1. Some CPAN Clients will suppress all and any of that output *on purpose*, and then only renders output *on failure*

2. In a long install job, unless your "wait" is in the scale of "several hours", the "wait time" will likely elapse while the person doing the install is away doing other things while they wait for all their other dependencies to be installed/updated.

Your solution might be appropriate if you assume every single installer is hand-operated, and installs only one dependency at a time.

But this is useless for anything automated that does lots of installs in a single job, or does bulk, automated updates/installs ( such as automated smoke boxes ).

The warning solution will subsequently only improve one aspect of this, in that when, at then end of a very long install job, find something unrelated breaking the install job because its tests fail bizzarely with

"required Net::DNS 1.0, this is version 0.98"

Or similar, their first "WTF?? Let me install that manually" will make the problem apparent at that time.

This means you're not actually making things "better" by not failing: anything that causes an update *will* be broken, it *will* not work.

All you're doing is delaying where it fails to a place its not useful.

Mon Feb 01 14:21:27 2016 SREZIC [...] cpan.org - Correspondence added

RT-Send-CC:

rwfranks [...] acm.org

On 2016-01-29 23:11:14, KENTNL wrote: Show quoted text

> On 2016-01-30 09:05:25, rwfranks@acm.org wrote:

> > > > A prominent message has been added to Makefile.PL followed by a long > > sleep to ensure that it remains on screen long enough to be noticed.

> > ^ and this part may on its own have no effect, because when you're > installing a > lot of dependencies ( where one is an upgrade trigger ), you're likely > to not > see anything, regardless of how long you set the wait for for several > reasons. > > 1. Some CPAN Clients will suppress all and any of that output *on > purpose*, and > then only renders output *on failure* > > 2. In a long install job, unless your "wait" is in the scale of > "several > hours", the "wait time" will likely elapse while the person doing the > install > is away doing other things while they wait for all their other > dependencies to > be installed/updated. > > Your solution might be appropriate if you assume every single > installer is > hand-operated, and installs only one dependency at a time. > > But this is useless for anything automated that does lots of installs > in a > single job, or does bulk, automated updates/installs ( such as > automated smoke > boxes ). > > The warning solution will subsequently only improve one aspect of > this, in that > when, at then end of a very long install job, find something unrelated > breaking > the install job because its tests fail bizzarely with > > "required Net::DNS 1.0, this is version 0.98" > > Or similar, their first "WTF?? Let me install that manually" will make > the > problem apparent at that time. > > This means you're not actually making things "better" by not failing: > anything > that causes an update *will* be broken, it *will* not work. > > All you're doing is delaying where it fails to a place its not useful.

I guess 1.04_01 implemented the fail, as my smoker machines just generated 27 fail reports. Not sure what I (and other CPAN Testers) should do now. Most test machines are fully automated, so the operator will never see that manual intervention is required. So "useless" fail reports will be sent in the future all the time. Just skipping the failing test in tester environments is not right either. For semi-manually operated testing systems it would be possible to remove the existing Net::DNS installation, but should I wait for the next stable one --- I usually never install devel versions, just test them --- or should I make an exception now? Also, the diagnostics message could be more helpful for the user. Maybe the contents of the .packlist could be printed, so the user knows what to delete. Or maybe there's an uninstall script somewhere in the CPAN. Or point the user to UNINST=1 (but no, this would not help, as the uninstall would happen only during "make install", and the fail would still happen in the "make test" phase). Maybe the easiest solution is to stick somehow to the existing installation directory? Maybe put again a dummy XS into the distribution? Regards, Slaven

Mon Feb 01 18:19:40 2016 rwfranks [...] acm.org - Correspondence added

Subject:	Re: [rt.cpan.org #108908] Installing recent version gets shadowed by old version
Date:	Mon, 1 Feb 2016 23:18:46 +0000
To:	bug-Net-DNS [...] rt.cpan.org
From:	Dick Franks <rwfranks [...] acm.org>

Slaven, Thanks for your take on this. I am unable to see the test reports yet because it seems to take many hours before they are posted on cpantesters.org, but it is clear from the log view that the t/00-upgrade-compatibility.t test is unworkable. It does surprise me that smokeboxes are not building the UUT in a clean Perl environment populated only to the extent needed to satisfy the declared module dependencies. Dick Dick Franks Show quoted text

________________________ On 1 February 2016 at 19:21, Slaven_Rezic via RT <bug-Net-DNS@rt.cpan.org> wrote:

> <URL: https://rt.cpan.org/Ticket/Display.html?id=108908 > > > On 2016-01-29 23:11:14, KENTNL wrote:

> > On 2016-01-30 09:05:25, rwfranks@acm.org wrote:

> > > > > > A prominent message has been added to Makefile.PL followed by a long > > > sleep to ensure that it remains on screen long enough to be noticed.

> > > > ^ and this part may on its own have no effect, because when you're > > installing a > > lot of dependencies ( where one is an upgrade trigger ), you're likely > > to not > > see anything, regardless of how long you set the wait for for several > > reasons. > > > > 1. Some CPAN Clients will suppress all and any of that output *on > > purpose*, and > > then only renders output *on failure* > > > > 2. In a long install job, unless your "wait" is in the scale of > > "several > > hours", the "wait time" will likely elapse while the person doing the > > install > > is away doing other things while they wait for all their other > > dependencies to > > be installed/updated. > > > > Your solution might be appropriate if you assume every single > > installer is > > hand-operated, and installs only one dependency at a time. > > > > But this is useless for anything automated that does lots of installs > > in a > > single job, or does bulk, automated updates/installs ( such as > > automated smoke > > boxes ). > > > > The warning solution will subsequently only improve one aspect of > > this, in that > > when, at then end of a very long install job, find something unrelated > > breaking > > the install job because its tests fail bizzarely with > > > > "required Net::DNS 1.0, this is version 0.98" > > > > Or similar, their first "WTF?? Let me install that manually" will make > > the > > problem apparent at that time. > > > > This means you're not actually making things "better" by not failing: > > anything > > that causes an update *will* be broken, it *will* not work. > > > > All you're doing is delaying where it fails to a place its not useful.

> > I guess 1.04_01 implemented the fail, as my smoker machines just generated > 27 fail reports. > > Not sure what I (and other CPAN Testers) should do now. Most test machines > are fully automated, so the operator will never see that manual > intervention is required. So "useless" fail reports will be sent in the > future all the time. Just skipping the failing test in tester environments > is not right either. For semi-manually operated testing systems it would be > possible to remove the existing Net::DNS installation, but should I wait > for the next stable one --- I usually never install devel versions, just > test them --- or should I make an exception now? > > Also, the diagnostics message could be more helpful for the user. Maybe > the contents of the .packlist could be printed, so the user knows what to > delete. Or maybe there's an uninstall script somewhere in the CPAN. Or > point the user to UNINST=1 (but no, this would not help, as the uninstall > would happen only during "make install", and the fail would still happen in > the "make test" phase). > > Maybe the easiest solution is to stick somehow to the existing > installation directory? Maybe put again a dummy XS into the distribution? > > Regards, > Slaven >

Mon Feb 01 22:11:46 2016 ether [...] cpan.org - Correspondence added

On 2016-02-01 15:19:40, rwfranks@acm.org wrote: Show quoted text

> It does surprise me that smokeboxes are not building the UUT in a > clean > Perl environment populated only to the extent needed to satisfy the > declared module dependencies.

Some do, but many do not, since installing on top of previous installations is a fair scenario to test. Personally, my "smoker" is just my main development machine, and I send cpantesters reports for everything I install or upgrade.

Tue Feb 02 08:16:55 2016 rwfranks [...] acm.org - Correspondence added

From:

rwfranks [...] acm.org

On Fri Nov 13 22:48:52 2015, KENTNL wrote: Show quoted text

> Somewhere between 0.83 and the current version, it appears the > location > Net::DNS installs to gets changed. > > On version 0.83, it installs to "${site}/${arch}/<>" but on 1.03 it > installs to > "${site}/<>" > > Which is unfortunate, because the former shadows the later, so even > after > upgrading, the upgraded version is not seen in @INC, only the older > version. > > Fortunately, there is a cure. > > Here's some code by HAARG++ > https://metacpan.org/source/HAARG/Devel-GlobalDestruction- > 0.13/Makefile.PL#L75-88 > > That example code checks for an older version of itself, and if a > version older > than a certain age is found, it appends code to make to request the > removal of > the ${arch} version so that it doesn't get shadowed. > > This is not a blanket "find and delete", but it only deletes the > problem file > from the arch directory corresponding to the install target.

Now you have seen me get my fingers burnt, just imagine what would have happened if I had been foolish enough to follow this suggestion!

Tue Feb 02 08:39:15 2016 rwfranks [...] acm.org - Correspondence added

From:

rwfranks [...] acm.org

On Fri Jan 29 23:11:14 2016, KENTNL wrote: Show quoted text

> The warning solution will subsequently only improve one aspect of > this, in that > when, at then end of a very long install job, find something unrelated > breaking > the install job because its tests fail bizzarely with > > "required Net::DNS 1.0, this is version 0.98" > > Or similar, their first "WTF?? Let me install that manually" will make > the > problem apparent at that time.

Which is better than no indication at all. The message now includes the location of the offending version.

Wed Mar 09 05:22:42 2016 NLNETLABS [...] cpan.org - Status changed from 'open' to 'resolved'

Wed Nov 02 19:56:38 2016 DBOOK [...] cpan.org - Correspondence added

On Tue Feb 02 08:16:55 2016, rwfranks@acm.org wrote: Show quoted text

> On Fri Nov 13 22:48:52 2015, KENTNL wrote:

> > Here's some code by HAARG++ > > https://metacpan.org/source/HAARG/Devel-GlobalDestruction- > > 0.13/Makefile.PL#L75-88 > > > > That example code checks for an older version of itself, and if a > > version older > > than a certain age is found, it appends code to make to request the > > removal of > > the ${arch} version so that it doesn't get shadowed. > > > > This is not a blanket "find and delete", but it only deletes the > > problem file > > from the arch directory corresponding to the install target.

> > Now you have seen me get my fingers burnt, just imagine what would > have happened if I had been foolish enough to follow this suggestion!

Both the automated testers and end users would have the older versions of Net::DNS properly cleaned up, and none of these would have failed.

Wed Nov 02 20:27:11 2016 lem [...] itverx.com.ve - Correspondence added

Subject:	Re: [rt.cpan.org #108908] Installing recent version gets shadowed by old version
Date:	Wed, 02 Nov 2016 17:26:48 -0700
To:	"Dan Book via RT" <bug-Net-DNS [...] rt.cpan.org>
From:	"Luis Muñoz" <lem [...] itverx.com.ve>

On 2 Nov 2016, at 16:56, Dan Book via RT wrote: Show quoted text

> Queue: Net-DNS > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=108908 > > > On Tue Feb 02 08:16:55 2016, rwfranks@acm.org wrote:

>> On Fri Nov 13 22:48:52 2015, KENTNL wrote:

>>> Here's some code by HAARG++ >>> https://metacpan.org/source/HAARG/Devel-GlobalDestruction- >>> 0.13/Makefile.PL#L75-88 >>> >>> That example code checks for an older version of itself, and if a >>> version older >>> than a certain age is found, it appends code to make to request the >>> removal of >>> the ${arch} version so that it doesn't get shadowed. >>> >>> This is not a blanket "find and delete", but it only deletes the >>> problem file >>> from the arch directory corresponding to the install target.

>> >> Now you have seen me get my fingers burnt, just imagine what would >> have happened if I had been foolish enough to follow this suggestion!

> > Both the automated testers and end users would have the older versions > of Net::DNS properly cleaned up, and none of these would have failed.

Covertly modifying the execution environment without knowledge and consent of the user is borderline hostile. Providing a prominent warning / refusing to run are more acceptable responses IMO. Best regards -lem

Wed Nov 02 20:55:40 2016 ether [...] cpan.org - Correspondence added

This is still a serious and unresolved issue; I created https://rt.cpan.org/Ticket/Display.html?id=118598 rather than reopening this, for cleaner history.

Wed Nov 02 21:37:09 2016 DBOOK [...] cpan.org - Correspondence added

On Wed Nov 02 20:27:11 2016, lem@itverx.com.ve wrote: Show quoted text

> Covertly modifying the execution environment without knowledge and > consent of the user is borderline hostile. Providing a prominent warning > / refusing to run are more acceptable responses IMO. > > Best regards > > -lem >

Bailing out of the installation would be acceptable. The current behavior to warn and wait 10 seconds is not.

Wed Nov 02 21:40:54 2016 DBOOK [...] cpan.org - Cc DBOOK added

Thu Nov 03 08:11:17 2016 LEONT [...] cpan.org - Correspondence added

On Wed Nov 02 20:27:11 2016, lem@itverx.com.ve wrote: Show quoted text

> On 2 Nov 2016, at 16:56, Dan Book via RT wrote: >

> > Queue: Net-DNS > > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=108908 > > > > > On Tue Feb 02 08:16:55 2016, rwfranks@acm.org wrote:

> >> On Fri Nov 13 22:48:52 2015, KENTNL wrote:

> >>> Here's some code by HAARG++ > >>> https://metacpan.org/source/HAARG/Devel-GlobalDestruction- > >>> 0.13/Makefile.PL#L75-88 > >>> > >>> That example code checks for an older version of itself, and if a > >>> version older > >>> than a certain age is found, it appends code to make to request the > >>> removal of > >>> the ${arch} version so that it doesn't get shadowed. > >>> > >>> This is not a blanket "find and delete", but it only deletes the > >>> problem file > >>> from the arch directory corresponding to the install target.

> >> > >> Now you have seen me get my fingers burnt, just imagine what would > >> have happened if I had been foolish enough to follow this suggestion!

> > > > Both the automated testers and end users would have the older versions > > of Net::DNS properly cleaned up, and none of these would have failed.

> > Covertly modifying the execution environment without knowledge and > consent of the user is borderline hostile. Providing a prominent warning > / refusing to run are more acceptable responses IMO. > > Best regards > > -lem >

Such a warning is unlikely to be seen, either because there's too much output (the default on CPAN.pm) or because the output is hidden (default on cpanm); rendering it moot. I believe there is a third option available in this case though: force installing to arch instead of lib if an old version is installed. I don't think this has precedent (and has the disadvantage of not being fatpack-compatible), but it shouldn't be all difficult to implement (passing `INST_LIB=$(INST_ARCHLIB)` to the WriteMakefile). Leon