Skip Menu |

This queue is for tickets about the Data-Dump-Streamer CPAN distribution.

Report information
The Basics
Id: 69197
Status: rejected
Priority: 0/
Queue: Data-Dump-Streamer
People
Owner: Nobody in particular
Requestors: adamk [...] cpan.org
Cc:
AdminCc:
Bug Information
Severity: Wishlist
Broken in: (no value)
Fixed in: (no value)

History Show all quoted text
  Thu Jun 30 01:44:37 2011 adamk [...] cpan.org - Ticket created
Subject: Don't block installation to ask about DDS
D:D:Streamer is used by many other high level modules, and when installing these high level modules, installation is blocked by D:D:Streamer to ask if it should install the DDS shortcut. Blocking installation of hundreds of other higher level applications to ask about an option feature probably unrelated to what the user is actually installing is very very annoying, and it should either. 1. Timeout the question 2. Just install it 3. Just don't install it 4. Split it out as a separate module My preference it for either 2 or 3
  Sun Apr 01 10:10:18 2012 yves [...] cpan.org - Correspondence added
On Thu Jun 30 01:44:37 2011, ADAMK wrote: Show quoted text
> D:D:Streamer is used by many other high level modules, and when > installing these high level modules, installation is blocked by > D:D:Streamer to ask if it should install the DDS shortcut. > > Blocking installation of hundreds of other higher level applications
to Show quoted text
> ask about an option feature probably unrelated to what the user is > actually installing is very very annoying, and it should either. > > 1. Timeout the question > 2. Just install it > 3. Just don't install it > 4. Split it out as a separate module > > My preference it for either 2 or 3
Er, we use Module::Build to ask y_n(), and before that we used to something from the MakeMaker framework for it, which I thought should be handled automatically by properly configured toolchains. Is this not correct?
  Sun Apr 01 10:10:22 2012 The RT System itself - Status changed from 'new' to 'open'
  Sun Apr 01 11:27:44 2012 yves [...] cpan.org - Severity Wishlist added
  Mon Apr 02 21:36:08 2012 adam [...] ali.as - Correspondence added
CC: adamk [...] cpan.org
Subject: Re: [rt.cpan.org #69197] Don't block installation to ask about DDS
Date: Mon, 2 Apr 2012 18:36:00 -0700
To: bug-Data-Dump-Streamer [...] rt.cpan.org
From: Adam Kennedy <adamkennedybackup [...] gmail.com>
Toolchains that have zero human interaction should deal with it properly. Unfortunately, if the installation is triggered by a human but the human is not present for the entire install or does not know the answer to the y_n question, than it hangs and does not timeout (to my knowledge). Adam On 1 April 2012 07:10, Yves via RT <bug-Data-Dump-Streamer@rt.cpan.org> wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=69197 > > > On Thu Jun 30 01:44:37 2011, ADAMK wrote:
>> D:D:Streamer is used by many other high level modules, and when >> installing these high level modules, installation is blocked by >> D:D:Streamer to ask if it should install the DDS shortcut. >> >> Blocking installation of hundreds of other higher level applications
> to
>> ask about an option feature probably unrelated to what the user is >> actually installing is very very annoying, and it should either. >> >> 1. Timeout the question >> 2. Just install it >> 3. Just don't install it >> 4. Split it out as a separate module >> >> My preference it for either 2 or 3
> > Er, we use Module::Build to ask y_n(), and before that we used to > something from the MakeMaker framework for it, which I thought should be > handled automatically by properly configured toolchains. Is this not > correct?
  Mon Apr 02 21:51:43 2012 twists [...] gmail.com - Correspondence added
Subject: Re: [rt.cpan.org #69197] Don't block installation to ask about DDS
Date: Mon, 2 Apr 2012 18:51:33 -0700
To: bug-Data-Dump-Streamer [...] rt.cpan.org
From: Joshua ben Jore <twists [...] gmail.com>
This sounds like a feature-request for M::B or EU::MM to have timeout facilities. Timeouts for package installation isn't appropriate as a package-level concern. Josh On Mon, Apr 2, 2012 at 6:36 PM, Reserved Local Account via RT <bug-Data-Dump-Streamer@rt.cpan.org> wrote: Show quoted text
>       Queue: Data-Dump-Streamer >  Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=69197 > > > Toolchains that have zero human interaction should deal with it properly. > > Unfortunately, if the installation is triggered by a human but the > human is not present for the entire install or does not know the > answer to the y_n question, than it hangs and does not timeout (to my > knowledge). > > Adam > > On 1 April 2012 07:10, Yves via RT <bug-Data-Dump-Streamer@rt.cpan.org> wrote:
>> <URL: https://rt.cpan.org/Ticket/Display.html?id=69197 > >> >> On Thu Jun 30 01:44:37 2011, ADAMK wrote:
>>> D:D:Streamer is used by many other high level modules, and when >>> installing these high level modules, installation is blocked by >>> D:D:Streamer to ask if it should install the DDS shortcut. >>> >>> Blocking installation of hundreds of other higher level applications
>> to
>>> ask about an option feature probably unrelated to what the user is >>> actually installing is very very annoying, and it should either. >>> >>> 1. Timeout the question >>> 2. Just install it >>> 3. Just don't install it >>> 4. Split it out as a separate module >>> >>> My preference it for either 2 or 3
>> >> Er, we use Module::Build to ask y_n(), and before that we used to >> something from the MakeMaker framework for it, which I thought should be >> handled automatically by properly configured toolchains. Is this not >> correct?
>
  Tue Apr 23 10:20:12 2013 SREZIC [...] cpan.org - Correspondence added
On 2012-04-02 21:51:43, twists@gmail.com wrote: Show quoted text
> This sounds like a feature-request for M::B or EU::MM to have timeout > facilities. Timeouts for package installation isn't appropriate as a > package-level concern.
EUMM (and maybe also MB) defines the environment variable PERL_MM_USE_DEFAULT. Automated installers may set this environment variable. If the Data::Dumper::Streamer distribution behaves correctly if this variable is set (i.e. continues immediately with the default answer), then I would say: reject this ticket. Regards, Slaven Show quoted text
> Josh > > On Mon, Apr 2, 2012 at 6:36 PM, Reserved Local Account via RT > <bug-Data-Dump-Streamer@rt.cpan.org> wrote:
> >       Queue: Data-Dump-Streamer > >  Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=69197 > > > > > Toolchains that have zero human interaction should deal with it
> properly.
> > > > Unfortunately, if the installation is triggered by a human but the > > human is not present for the entire install or does not know the > > answer to the y_n question, than it hangs and does not timeout (to
> my
> > knowledge). > > > > Adam > > > > On 1 April 2012 07:10, Yves via RT <bug-Data-Dump-
> Streamer@rt.cpan.org> wrote:
> >> <URL: https://rt.cpan.org/Ticket/Display.html?id=69197 > > >> > >> On Thu Jun 30 01:44:37 2011, ADAMK wrote:
> >>> D:D:Streamer is used by many other high level modules, and when > >>> installing these high level modules, installation is blocked by > >>> D:D:Streamer to ask if it should install the DDS shortcut. > >>> > >>> Blocking installation of hundreds of other higher level
> applications
> >> to
> >>> ask about an option feature probably unrelated to what the user is > >>> actually installing is very very annoying, and it should either. > >>> > >>> 1. Timeout the question > >>> 2. Just install it > >>> 3. Just don't install it > >>> 4. Split it out as a separate module > >>> > >>> My preference it for either 2 or 3
> >> > >> Er, we use Module::Build to ask y_n(), and before that we used to > >> something from the MakeMaker framework for it, which I thought
> should be
> >> handled automatically by properly configured toolchains. Is this
> not
> >> correct?
> >
  Mon Dec 09 11:38:52 2013 SREZIC [...] cpan.org - Correspondence added
On 2013-04-23 10:20:12, SREZIC wrote: Show quoted text
> On 2012-04-02 21:51:43, twists@gmail.com wrote:
> > This sounds like a feature-request for M::B or EU::MM to have timeout > > facilities. Timeouts for package installation isn't appropriate as a > > package-level concern.
> > EUMM (and maybe also MB) defines the environment variable > PERL_MM_USE_DEFAULT. Automated installers may set this environment > variable. If the Data::Dumper::Streamer distribution behaves correctly > if this variable is set (i.e. continues immediately with the default > answer), then I would say: reject this ticket.
I checked right now with Data-Dump-Streamer-2.36. If PERL_MM_USE_DEFAULT is set, then the installation is not blocked. So no problem (anymore?). Regards, Slaven Show quoted text
> > Regards, > Slaven >
> > Josh > > > > On Mon, Apr 2, 2012 at 6:36 PM, Reserved Local Account via RT > > <bug-Data-Dump-Streamer@rt.cpan.org> wrote:
> > >       Queue: Data-Dump-Streamer > > >  Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=69197 > > > > > > > Toolchains that have zero human interaction should deal with it
> > properly.
> > > > > > Unfortunately, if the installation is triggered by a human but the > > > human is not present for the entire install or does not know the > > > answer to the y_n question, than it hangs and does not timeout (to
> > my
> > > knowledge). > > > > > > Adam > > > > > > On 1 April 2012 07:10, Yves via RT <bug-Data-Dump-
> > Streamer@rt.cpan.org> wrote:
> > >> <URL: https://rt.cpan.org/Ticket/Display.html?id=69197 > > > >> > > >> On Thu Jun 30 01:44:37 2011, ADAMK wrote:
> > >>> D:D:Streamer is used by many other high level modules, and when > > >>> installing these high level modules, installation is blocked by > > >>> D:D:Streamer to ask if it should install the DDS shortcut. > > >>> > > >>> Blocking installation of hundreds of other higher level
> > applications
> > >> to
> > >>> ask about an option feature probably unrelated to what the user > > >>> is > > >>> actually installing is very very annoying, and it should either. > > >>> > > >>> 1. Timeout the question > > >>> 2. Just install it > > >>> 3. Just don't install it > > >>> 4. Split it out as a separate module > > >>> > > >>> My preference it for either 2 or 3
> > >> > > >> Er, we use Module::Build to ask y_n(), and before that we used to > > >> something from the MakeMaker framework for it, which I thought
> > should be
> > >> handled automatically by properly configured toolchains. Is this
> > not
> > >> correct?
> > >
  Thu Dec 24 22:53:03 2015 yves [...] cpan.org - Correspondence added
As per Slavens checking, if the correct env vars are set we wont block. So I am rejecting this ticket. Thanks for the report, and sorry for the embarrassingly long delay in dealing with it.
  Thu Dec 24 22:53:15 2015 yves [...] cpan.org - Status changed from 'open' to 'rejected'