Skip Menu |
 

This queue is for tickets about the Module-Build CPAN distribution.

Report information
The Basics
Id: 58445
Status: open
Priority: 0/
Queue: Module-Build

People
Owner: Nobody in particular
Requestors: ANDK [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Wishlist
Broken in: (no value)
Fixed in:
  • 0.3603
  • 0.3607
  • 0.36_11



Subject: overzealous usage of configure_requires considered harmful
Download (untitled) / with headers
text/plain 1.3k
TINITA has uploaded Parse-BBCode-0.10 these days. After uploading the META.yml contains the lines: configure_requires: Module::Build: 0.36 When asking her if this is intentional she answers she doesn't know about this. I have reproduced the META.yml with "./Build dist" on my own machine and I can confirm that there is no feedback provided that the META.yml will contain this configure_requires condition. There is no hint about why the condition must be met and no obvious way to prevent the production of the configure_requires line. Now comes the problem: people who prefer to build OS specific packages to install software are easily locked out by such conditions. Module::Build is part of the perl package on all known Debian variants. So to build a debian package for Parse::BBCode now would require to build a new custom perl package with Module::Build 0.36 before the Parse::BBCode package can be built. Please be more tolerant against people who want to use their current perl and are not able to customize and build a new perl package every few weeks. Minimum versions are OK for some packages but especially toolchain packages must have a wider horizon and should not declare incompatibility every few months. I've tried MB 0.3603, 0.3607 and 0.36_11: all behave the same. For a reference: I've found ticket 28563 which demanded the configure_requires act.
Subject: Re: [rt.cpan.org #58445] overzealous usage of configure_requires considered harmful
Date: Wed, 16 Jun 2010 07:17:11 -0400
To: bug-Module-Build [...] rt.cpan.org
From: David Golden <dagolden [...] cpan.org>
Download (untitled) / with headers
text/plain 826b
On Wed, Jun 16, 2010 at 6:42 AM, Andreas Koenig via RT <bug-Module-Build@rt.cpan.org> wrote: Show quoted text
> When asking her if this is intentional she answers she doesn't know > about this. I have reproduced the META.yml with "./Build dist" on my own > machine and I can confirm that there is no feedback provided that the > META.yml will contain this configure_requires condition.
This is an intentional design decision. From Module::Build::API: auto_configure_requires [version 0.34] This parameter determines whether Module::Build will add itself automatically to configure_requires (and build_requires) if Module::Build is not already there. The required version will be the last 'major' release, as defined by the decimal version truncated to two decimal places (e.g. 0.34, instead of 0.3402). The default value is true.
Subject: Re: [rt.cpan.org #58445] overzealous usage of configure_requires considered harmful
Date: Wed, 16 Jun 2010 08:33:22 -0400
To: bug-Module-Build [...] rt.cpan.org
From: David Golden <dagolden [...] cpan.org>
Download (untitled) / with headers
text/plain 1.2k
On Wed, Jun 16, 2010 at 7:17 AM, David Golden <dagolden@cpan.org> wrote: Show quoted text
> On Wed, Jun 16, 2010 at 6:42 AM, Andreas Koenig via RT > <bug-Module-Build@rt.cpan.org> wrote:
>> When asking her if this is intentional she answers she doesn't know >> about this. I have reproduced the META.yml with "./Build dist" on my own >> machine and I can confirm that there is no feedback provided that the >> META.yml will contain this configure_requires condition.
> > This is an intentional design decision.  From Module::Build::API: > > auto_configure_requires > >    [version 0.34] > >    This parameter determines whether Module::Build will add itself > automatically to configure_requires (and build_requires) if > Module::Build is not already there. The required version will be the > last 'major' release, as defined by the decimal version truncated to > two decimal places (e.g. 0.34, instead of 0.3402). The default value > is true.
To clarify -- authors who use Module::Build *should* declare Module::Build in configure_requires with a minimum version sufficient to execute the Build.PL. If they do not, the auto_configure_requires is a safety net. I will patch Module::Build to warn authors about this and note that configure_requires is being set automatically. David
Download (untitled) / with headers
text/plain 735b
Just a comment on OS packages: Nowadays the files from a module distribution end up in different locations than the one from the core. E.g. /usr/share/perl/5.10.0/Module/Build.pm (core lenny) vs. /usr/share/perl5/Module/Build.pm (own debian package) There are some exceptions like in Module::Build: it provides /usr/bin/ config_data, which is also in core, so this will create a conflict, and when building the package you have to do some dpkg foo to avoid this conflict. Works both in dh-make-perl and cpan2dist. So if one can be bothered to do this manual workaround when building then this problem goes away. But I also think there should be a better default - requirements for config_requires should be as low as possible.
Subject: Re: [rt.cpan.org #58445] overzealous usage of configure_requires considered harmful
Date: Wed, 16 Jun 2010 11:14:21 -0400
To: bug-Module-Build [...] rt.cpan.org
From: David Golden <dagolden [...] cpan.org>
Download (untitled) / with headers
text/plain 1.1k
On Wed, Jun 16, 2010 at 10:49 AM, Tina Muller via RT <bug-Module-Build@rt.cpan.org> wrote: Show quoted text
> But I also think there should be a better default - requirements for > config_requires should be as low as possible.
Historically, users were responsible for ensuring they could run configuration files like Build.PL. Authors complained that this was too burdensome on end users and led to frequent complaints to the authors about requiring an up-to-date toolchain module. Thus, authors clamored for an automated solution. After years of discussion and coding and testing, configure_requires was introduced to allow CPAN clients to detect and install configuration dependencies. Many authors still ignore this. Some complain that the toolchain should deal with it. To make life simpler for the majority of authors and users, Module::Build automatically adds a configure_requires if authors cannot be bothered to do so. If the consequence of this is that an authors' modules can't easily be packaged for a particular distribution, a very easy solution is for the author to explicitly declare the real, minimum requirements in their modules.
Download (untitled) / with headers
text/plain 669b
I'm maybe getting off topic now, but adding a debian/preinst and a debian/postrm file would be really helpful for automatically creating debian packages. So the preinst file should contain: #!/bin/sh dpkg-divert --package libmodule-build-perl --add --rename --divert /usr/ bin/config_data.perl /usr/bin/config_data and the postrm: dpkg-divert --package libmodule-build-perl --remove --rename --divert / usr/bin/config_data.perl /usr/bin/config_data This would save many many developers creating debian packages lots of time =) At the moment I believe many just give up because the workaround is not easy to find. Would be glad if you could think about it. tina
Download (untitled) / with headers
text/plain 409b
Show quoted text
> If the consequence of this is that an > authors' modules can't easily be packaged for a particular > distribution, a very easy solution is for the author to explicitly > declare the real, minimum requirements in their modules.
Well the problem is the default, and that many authors are not aware of the consequences because they never build debian packages theirselves. A warning at least would be nice.
Download (untitled) / with headers
text/plain 632b
Yeah, it would be nice if we could auto-detect which features of M-B an author is using, and then figure out when those features were introduced (or when they had their latest major bugs fixed), but that's too hard. Another idea we've floated around for a long time is to have a way for authors to auto-embed the version of M-B necessary for building right in the distribution. There are some problems with this too, but ultimately I think they're solvable. -Keb On Wed Jun 16 10:49:31 2010, TINITA wrote: Show quoted text
> But I also think there should be a better default - requirements for > config_requires should be as low as possible.
On Wed Jun 16 11:48:54 2010, KWILLIAMS wrote: Show quoted text
> > -Keb
Um, make that Ken. -Ken
Subject: Re: [rt.cpan.org #58445] overzealous usage of configure_requires considered harmful
Date: Wed, 16 Jun 2010 09:56:56 -0700
To: bug-Module-Build [...] rt.cpan.org
From: Eric Wilhelm <enobacon [...] gmail.com>
Download (untitled) / with headers
text/plain 982b
# from Andreas Koenig via RT # on Wednesday 16 June 2010 03:42: Show quoted text
>Now comes the problem: people who prefer to build OS specific packages >to install software are easily locked out by such conditions. >Module::Build is part of the perl package on all known Debian > variants. So to build a debian package for Parse::BBCode now would > require to build a new custom perl package with Module::Build 0.36 > before the Parse::BBCode package can be built.
Why do they need to build a new perl package? The packager needs a Module::Build which satisfies configure_requires. It doesn't need to be in the core path or even in a debian package. If this is not the case, something in their packaging tools is not working. --Eric -- Introducing change is like pulling off a bandage: the pain is a memory almost as soon as you feel it. --Paul Graham --------------------------------------------------- http://scratchcomputing.com ---------------------------------------------------
Download (untitled) / with headers
text/plain 489b
The problem is the default. If I understand correctly, the default will by 0.42 on the day that 0.42 is released. Where is the elasticity that perl always was famous for? And sorry, I'm not as fluent in making debs as I'd like, so no debate about broken packaging tools, please. I'm complaining about missing elasticity. I plead for a hardcoded value of say 0.26 or some such. An explicit value that should be justified by a human brain, not a substring of the current value of $VERSION.
Download (untitled) / with headers
text/plain 799b
On Thu Jun 17 01:07:42 2010, ANDK wrote: Show quoted text
> The problem is the default. If I understand correctly, the default will > by 0.42 on the day that 0.42 is released. Where is the elasticity that > perl always was famous for? > > And sorry, I'm not as fluent in making debs as I'd like, so no debate > about broken packaging tools, please. > > I'm complaining about missing elasticity. I plead for a hardcoded value > of say 0.26 or some such. An explicit value that should be justified by > a human brain, not a substring of the current value of $VERSION.
I think I agree. I can't think of any reason why we would need to require anything more than 0.36 (Added support for PERL_MB_OPT, necessary for local::lib and a few other features) or maybe 0.3601 (upgrades more cleanly with build_requires). Leon
Subject: Re: [rt.cpan.org #58445] overzealous usage of configure_requires considered harmful
Date: Mon, 10 Sep 2012 23:15:57 -0700
To: bug-Module-Build [...] rt.cpan.org
From: Eric Wilhelm <enobacon [...] gmail.com>
Download (untitled) / with headers
text/plain 1.5k
# from Leon Timmermans via RT on Saturday 28 July 2012: Show quoted text
>On Thu Jun 17 01:07:42 2010, ANDK wrote:
>> I'm complaining about missing elasticity. I plead for a hardcoded >> value of say 0.26 or some such. An explicit value that should be >> justified by a human brain, not a substring of the current value of >> $VERSION.
> >I think I agree. I can't think of any reason why we would need to >require anything more than 0.36 (Added support for PERL_MB_OPT, >necessary for local::lib and a few other features) or maybe 0.3601 >(upgrades more cleanly with build_requires).
I believe the original rationale behind "just require the current version" was to err on the side of always being sure that authors were shipping something which would successfully install. If a version of M::B gets out with an incorrect default, there is a chance that it remains unfixed while being used to roll dists, thus requiring those authors to upgrade and reship just to fix M::B's error (and finding out the hard way that their dist is not installable because of it.) If an author wants to back-off the requirement to something older, they have that control and responsibility. If M::B starts hard-coding something, it would have to be verified at every release or it will go stale. It seems like it might be better to have a per-install configurable value for the author to set (but then, that could go stale too.) --Eric -- --------------------------------------------------- http://scratchcomputing.com ---------------------------------------------------
CC: ANDK [...] cpan.org
Subject: Re: [rt.cpan.org #58445] overzealous usage of configure_requires considered harmful
Date: Tue, 11 Sep 2012 11:43:56 +0200
To: bug-Module-Build [...] rt.cpan.org
From: Andreas Koenig <andreas.koenig.7os6VVqR [...] franz.ak.mind.de>
Download (untitled) / with headers
text/plain 2.2k
"Eric Wilhelm via RT" <bug-Module-Build@rt.cpan.org> writes: Show quoted text
> I believe the original rationale behind "just require the current > version" was to err on the side of always being sure that authors were > shipping something which would successfully install.
Yes, but it is still erring. From a software that claims to provide a MakeMaker replacement, erring on such an important scale is a major obstacle for getting accepted. MakeMaker has, as far as I can remember, always had a good measure for the needed resilience. Deliberately refusing to provide broad compatibility is putting a burden on end users. Show quoted text
> If a version of > M::B gets out with an incorrect default, there is a chance that it > remains unfixed while being used to roll dists, thus requiring those > authors to upgrade and reship just to fix M::B's error (and finding out > the hard way that their dist is not installable because of it.)
Unless we are in an echo chamber, we should estimate that there are significant more end users than there are authors. If there is really a trade-off between burdon for end users and burden for authors, then we should most often shift this burden on the author. The reason should be so obvious that I don't believe I have to explain it here. Show quoted text
> If an author wants to back-off the requirement to something older, they > have that control and responsibility. If M::B starts hard-coding > something, it would have to be verified at every release or it will go > stale.
Does Module::Build not have a release managers guide? Maybe it should. For the record, the story went like this: author A of package P used Module::Build, Module::Build put the insane dependency requirement on the end user. Author A did not get informed. User U got hurt by unnecessary requirements. What happens in such situations: as end user I have to complain to author A because I do not know where the bug sits. And potentially I have to complain to N authors about the nonsense dependency they have. That's an affront against the end user community. Show quoted text
> It seems like it might be better to have a per-install > configurable value for the author to set (but then, that could go stale > too.)
Author A usually has no solid knowledge to tell which version of Module::Build is required. If Module::Build does not get it right, so how should she? -- andreas
Download (untitled) / with headers
text/plain 1.7k
On Thu Jun 17 01:07:42 2010, ANDK wrote: Show quoted text
> The problem is the default. If I understand correctly, the default will > by 0.42 on the day that 0.42 is released.
That is not correct. The default depends on the module release manager's environment. If they don't upgrade from 0.26 to 0.42, and keep testing with 0.26, the default stays at 0.26. The day they upgrade to 0.42 and test their distribution with it, the default changes to 0.42. Show quoted text
> I'm complaining about missing elasticity. I plead for a hardcoded value > of say 0.26 or some such. An explicit value that should be justified by > a human brain, not a substring of the current value of $VERSION.
Then as soon as an author uses some feature added after 0.26, it breaks (blows up quite painfully) for the end user in some very non-obvious way. To avoid that, the author has to be aware of when every single feature they're using was added, or a relevant bug fixed, which is basically impossible. The only fallback would be to test with all released versions from 0.26 to the author's installed version - which should be done automatically, since this is all just to have a default when the author doesn't set a minimum value. That is a very bad trade-off. A much better strategy for an author is to keep careful control over what version of the build/release tools they are using, and require that as a minimum version. As always, if the end user wants to ignore the warning and just force the install anyway, they're able to do so, because they've been given the information cleanly about what the author believes is the required prerequisite. If the situation is so terrible that the packaging tools need to croak instead of having a reasonable default, we can debate that. But defaulting to an untested prerequisite value is IMO a non-starter.
Download (untitled) / with headers
text/plain 1.3k
On Tue Sep 11 05:44:30 2012, andreas.koenig.7os6VVqR@franz.ak.mind.de wrote: Show quoted text
> > From a software that claims to provide a > MakeMaker replacement, erring on such an important scale is a major > obstacle for getting accepted.
I'm sorry, I am completely tired of that line. M::B is a MakeMaker *alternative*. It does some things differently. Intentionally. Better. Or worse, if your opinion is different. But every person with an ax to grind comes and says "M::B will never replace MM until you change this." Guess what - M::B will never replace MM *EVER*. Neither will anything else, until perl itself, and even Perl itself, are replaced. Which is also basically never. People will continue to use MM whenever they want to, and the supply of such people will never run out. So in the meantime, we can focus on building a reasonable build & install system the way we think is useful to the community. Show quoted text
> MakeMaker has, as far as I can remember, > always had a good measure for the needed resilience.
As far as I'm aware, MakeMaker has never had anything even close to approaching any semblance of prerequisite detection. This is [part of] the reason no author can ever upgrade their MakeMaker and use its new features without either a) hand-setting the prerequisite, or b) breaking things badly for any end user who didn't guess through mind-reading that they needed to upgrade too.
Subject: Re: [rt.cpan.org #58445] overzealous usage of configure_requires considered harmful
Date: Tue, 11 Sep 2012 11:54:53 -0400
To: bug-Module-Build [...] rt.cpan.org
From: David Golden <dagolden [...] cpan.org>
Download (untitled) / with headers
text/plain 1.8k
Show quoted text
> On Thu Jun 17 01:07:42 2010, ANDK wrote:
>> The problem is the default. If I understand correctly, the default will >> by 0.42 on the day that 0.42 is released.
> > That is not correct. The default depends on the module release manager's > environment. If they don't upgrade from 0.26 to 0.42, and keep testing with 0.26, > the default stays at 0.26. The day they upgrade to 0.42 and test their > distribution with it, the default changes to 0.42.
Since I implemented this "feature" when I was the active M::B maintainer, I figure I should chime in. Going way back, the big knock on M::B was that users had to upgrade M::B all the time to get things to work. Then configure_requires was invented and supported in the core -- meaning that any distribution that put a sufficient version of M::B in configure_requires would just work on a new-enough perl/toolchain. But distribution authors aren't very good at actually doing things that make things easier for end-users and the complaints continued. I decided that the right way to deal with this is to have M::B default to setting a very recent M::B as configure_requires by default. I didn't want to do the work to analyze the historical feature set by version or to analyze the Build process to detect features used because that's hard and annoying and probably creates more bugs than it solves. Thoughtful authors who take the time to pay attention can turn off the automatic configure_requires or can provide their own configure_requires instead. I strongly encourage authors to declare their dependencies -- including configure_requires -- explicitly. The default is designed to do something simple and stupid and sufficient for most users in the face of lazy authors who don't declare their own requirements. David -- David Golden <dagolden@cpan.org> Take back your inbox! → http://www.bunchmail.com/ Twitter/IRC: @xdg
Download (untitled) / with headers
text/plain 617b
On Tue Sep 11 11:55:33 2012, DAGOLDEN wrote: Show quoted text
> I decided that the right way to deal with this is to have M::B default > to setting a very recent M::B as configure_requires by default.
Wait a sec - what does "very recent" mean here? I thought it meant "the version of M::B being used right now on the author's machine". Is it actually the most-recently-released version on CPAN? If so, the criticisms I had of defaulting to an old CPAN version apply [nearly] equally to the new CPAN version, namely that it's specifying a prereq that hasn't actually been tested before release. Should I eat my previous words?
Subject: Re: [rt.cpan.org #58445] overzealous usage of configure_requires considered harmful
Date: Tue, 11 Sep 2012 12:04:32 -0400
To: bug-Module-Build [...] rt.cpan.org
From: David Golden <dagolden [...] cpan.org>
Download (untitled) / with headers
text/plain 669b
On Tue, Sep 11, 2012 at 12:02 PM, Ken Williams via RT <bug-Module-Build@rt.cpan.org> wrote: Show quoted text
> On Tue Sep 11 11:55:33 2012, DAGOLDEN wrote:
>> I decided that the right way to deal with this is to have M::B default >> to setting a very recent M::B as configure_requires by default.
> > Wait a sec - what does "very recent" mean here? I thought it meant "the > version of M::B being used right now on the author's machine". Is it > actually the most-recently-released version on CPAN?
IIRC, it's current version on author's machine, truncated to "X.YY". David -- David Golden <dagolden@cpan.org> Take back your inbox! → http://www.bunchmail.com/ Twitter/IRC: @xdg
Subject: Re: [rt.cpan.org #58445] overzealous usage of configure_requires considered harmful
Date: Tue, 11 Sep 2012 11:45:11 -0500
To: bug-Module-Build [...] rt.cpan.org
From: Ken Williams <kwilliams [...] cpan.org>
Download (untitled) / with headers
text/plain 216b
On Tue, Sep 11, 2012 at 11:05 AM, David Golden via RT < bug-Module-Build@rt.cpan.org> wrote: Show quoted text
> > IIRC, it's current version on author's machine, truncated to "X.YY". >
Okay, good. That's what I thought. =) -Ken
CC: ANDK [...] cpan.org
Subject: Re: [rt.cpan.org #58445] overzealous usage of configure_requires considered harmful
Date: Wed, 12 Sep 2012 08:38:33 +0200
To: bug-Module-Build [...] rt.cpan.org
From: Andreas Koenig <andreas.koenig.7os6VVqR [...] franz.ak.mind.de>
Download (untitled) / with headers
text/plain 2.5k
"David Golden via RT" <bug-Module-Build@rt.cpan.org> writes: Show quoted text
> Since I implemented this "feature" when I was the active M::B > maintainer, I figure I should chime in.
Thanks. I didn't know how this decision came about, I thought it was really intended as it is. Show quoted text
> Going way back, the big knock on M::B was that users had to upgrade > M::B all the time to get things to work. Then configure_requires was > invented and supported in the core -- meaning that any distribution > that put a sufficient version of M::B in configure_requires would just > work on a new-enough perl/toolchain. > > But distribution authors aren't very good at actually doing things > that make things easier for end-users and the complaints continued. > > I decided that the right way to deal with this is to have M::B default > to setting a very recent M::B as configure_requires by default.
You wanted a very recent but you coded the one that is installed on the author's machine cut to a mantissa of two digits. So on the day somebody bumps to 0.41 the next round of needless annoyance for end users and system integrators comes down upon us automatically. Hope remains it won't happen. Show quoted text
> I didn't want to do the work to analyze the historical feature set by > version or to analyze the Build process to detect features used > because that's hard and annoying and probably creates more bugs than > it solves.
Fair enough, in times of huge overhauls and numerous bugfixes in every version there is not much to gain by doing this sort of homework. But in times of relative stability and less serious changes between versions it's harmful to declare higher dependencies than the correct one. Show quoted text
> Thoughtful authors who take the time to pay attention can turn off the > automatic configure_requires or can provide their own > configure_requires instead. > > I strongly encourage authors to declare their dependencies -- > including configure_requires -- explicitly.
Of course, but encouraging authors to do their homework is no excuse for not doing it right in the first place. Show quoted text
> The default is designed to do something simple and stupid and > sufficient for most users in the face of lazy authors who don't > declare their own requirements.
"Something simple and stupid" sounds like a good characterization, excuse me for picking that up. If one would code '0.40' there statically, nothing would change compared to status quo. And bumping that only once you know that '0.41' has had time to propagate and be widely deployed would solve my gripe. It would be a tiny bit less simple and huge amount less stupid. -- andreas
Subject: Re: [rt.cpan.org #58445] overzealous usage of configure_requires considered harmful
Date: Wed, 12 Sep 2012 00:59:36 -0700
To: bug-Module-Build [...] rt.cpan.org
From: Eric Wilhelm <enobacon [...] gmail.com>
Download (untitled) / with headers
text/plain 2.4k
# from (Andreas J. Koenig) via RT on Tuesday 11 September 2012: Show quoted text
>> The default is designed to do something simple and stupid and >> sufficient for most users in the face of lazy authors who don't >> declare their own requirements.
> >"Something simple and stupid" sounds like a good characterization, >excuse me for picking that up. > >If one would code '0.40' there statically, nothing would change >compared to status quo. And bumping that only once you know that >'0.41' has had time to propagate and be widely deployed would solve >my gripe. It would be a tiny bit less simple and huge amount less >stupid.
The "simple and stupid" thing is going to be more dependable than this clever bug. If *anything* changed from 0.40 to 0.41, then you have a chance of users getting caught without a working installer because of this optimization -- regardless of how "widely-deployed" it is. Repeat that risk on every new release of M::B. Is the time saved in upgrading M::B really that large? How often is there a new version which doesn't fix some bug or add a feature on the installation side? I think the maintenance load and the risk of bugs is not worth the savings (whatever that savings is... if upgrading takes too long, let's fix that instead.) Show quoted text
>> If a version of >> M::B gets out with an incorrect default, there is a chance that it >> remains unfixed while being used to roll dists, thus requiring >> those authors to upgrade and reship just to fix M::B's error (and >> finding out the hard way that their dist is not installable because >> of it.)
> >...we should estimate that there are >significant more end users than there are authors. If there is really >a trade-off between burdon for end users and burden for authors, then >we should most often shift this burden on the author.
The end users still lose here waiting days for the author to fix the bug introduced by M::B attempting to save a few bits and tics. I know it's saying "upgrade, upgrade", but really: how viable is it to *not* upgrade M::B if authors (whose recently released modules are being installed) are actively upgrading it and possibly using new features? You're not getting configure_requires for a M::B which came out *after* the module being installed, right? With all of this change, how long will it take for a statically-coded value to cause a bug? --Eric -- --------------------------------------------------- http://scratchcomputing.com ---------------------------------------------------
Subject: Re: [rt.cpan.org #58445] overzealous usage of configure_requires considered harmful
Date: Wed, 12 Sep 2012 07:08:33 -0400
To: bug-Module-Build [...] rt.cpan.org
From: David Golden <dagolden [...] cpan.org>
Download (untitled) / with headers
text/plain 1.1k
On Wed, Sep 12, 2012 at 2:38 AM, (Andreas J. Koenig) via RT <bug-Module-Build@rt.cpan.org> wrote: Show quoted text
> "Something simple and stupid" sounds like a good characterization, > excuse me for picking that up.
Sorry. That might be an Americanism -- the KISS principle: http://en.wikipedia.org/wiki/KISS_principle Show quoted text
> If one would code '0.40' there statically, nothing would change compared > to status quo. And bumping that only once you know that '0.41' has had > time to propagate and be widely deployed would solve my gripe. It would > be a tiny bit less simple and huge amount less stupid.
My view is that if M::B hard-coded a value, then it is accepting responsibility for getting it right. When I was maintainer, I didn't want that responsibility. Therefore, M::B follows a "fail safe" principle, which is that if the author doesn't specify something (or turn off auto config requires), then the prereq is the version they are using to ship because that is the only one known to work. Anything else is a guess, which is eventually going to be wrong. David -- David Golden <dagolden@cpan.org> Take back your inbox! → http://www.bunchmail.com/ Twitter/IRC: @xdg
Subject: Re: [rt.cpan.org #58445] overzealous usage of configure_requires considered harmful
Date: Wed, 12 Sep 2012 07:27:28 -0500
To: bug-Module-Build [...] rt.cpan.org
From: Ken Williams <kwilliams [...] cpan.org>
Download (untitled) / with headers
text/plain 1.1k
On Wed, Sep 12, 2012 at 1:38 AM, (Andreas J. Koenig) via RT < bug-Module-Build@rt.cpan.org> wrote: Show quoted text
> > If one would code '0.40' there statically, nothing would change compared > to status quo. And bumping that only once you know that '0.41' has had > time to propagate and be widely deployed would solve my gripe. It would > be a tiny bit less simple and huge amount less stupid. >
Suppose we did that, imagine the breakage scenario. Suppose the author installs 0.42 or 0.43, and we don't think they've propagated very far, so the hard-coded value is still 0.40. Then if the author uses *any* features that were added after 0.40, or exercises any code that was buggy in 0.40 but fixed later, then this just BLOWS UP or WORKS WRONG on the end user's machine. So the author, if he/she wants to be a responsible person and not risk blowups, has to 1) go check what the hard-coded value is, and 2) figure out what all these feature & bug changes are relative to their installed version, and 3) not use them. So there was no point in upgrading in the first place. So they should never upgrade. So we can never add new features. So the project is essentially dead.
CC: ANDK [...] cpan.org
Subject: Re: [rt.cpan.org #58445] overzealous usage of configure_requires considered harmful
Date: Thu, 13 Sep 2012 08:30:52 +0200
To: bug-Module-Build [...] rt.cpan.org
From: Andreas Koenig <andreas.koenig.7os6VVqR [...] franz.ak.mind.de>
Download (untitled) / with headers
text/plain 7.4k
"David Golden via RT" <bug-Module-Build@rt.cpan.org> writes: Show quoted text
> My view is that if M::B hard-coded a value, then it is accepting > responsibility for getting it right. When I was maintainer, I didn't > want that responsibility.
Fair enough, but you're just trading different kinds of responsibilities. The responsibility to not introduce new bugs and the responsibility to not decrease the resilience and the reliabilty of the CPAN as a whole are just two of the responsibilities you cannot really escape when you release something. Show quoted text
> Therefore, M::B follows a "fail safe" > principle, which is that if the author doesn't specify something (or > turn off auto config requires), then the prereq is the version they > are using to ship because that is the only one known to work.
I'm not so sure that you know it to work. All you know is that this (current) Module::Build was able to generate that (current) release of distro X. You do not know whether it will work for installing on the end user machine. You do not know, say, whether this release will eat files on the end user machine. You do not know it for the previous version either, but if you allow the previous version, there is a chance that the enduser will find out. Or by virtue of statistical evidence there will be a finding on cpantesters that tells you something about which bug is at work. Show quoted text
> Anything else is a guess, which is eventually going to be wrong.
Sure, where there is development there are bugs. The bug I'm reporting is just one of many, but it is a meta bug, and that is why I'm so serious about it. "Eric Wilhelm via RT" <bug-Module-Build@rt.cpan.org> writes: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=58445 > > > # from (Andreas J. Koenig) via RT on Tuesday 11 September 2012:
>>> The default is designed to do something simple and stupid and >>> sufficient for most users in the face of lazy authors who don't >>> declare their own requirements.
>> >>"Something simple and stupid" sounds like a good characterization, >>excuse me for picking that up. >> >>If one would code '0.40' there statically, nothing would change >>compared to status quo. And bumping that only once you know that >>'0.41' has had time to propagate and be widely deployed would solve >>my gripe. It would be a tiny bit less simple and huge amount less >>stupid.
> > The "simple and stupid" thing is going to be more dependable than this > clever bug. If *anything* changed from 0.40 to 0.41, then you have a > chance of users getting caught without a working installer because of > this optimization -- regardless of how "widely-deployed" it is.
If *anything* changed, then there is a chance of users being caught with a freshly introduced bug. Show quoted text
> Repeat that risk on every new release of M::B. > > Is the time saved in upgrading M::B really that large?
It depends. Time that can be shifted is in general not hurting as much as time that must be spent here and now. Multiply that time by the number of sysadmins that will be affected. Show quoted text
> How often is > there a new version which doesn't fix some bug or add a feature on the > installation side? I think the maintenance load and the risk of bugs is > not worth the savings (whatever that savings is... if upgrading takes > too long, let's fix that instead.)
Show quoted text
>>> If a version of >>> M::B gets out with an incorrect default, there is a chance that it >>> remains unfixed while being used to roll dists, thus requiring >>> those authors to upgrade and reship just to fix M::B's error (and >>> finding out the hard way that their dist is not installable because >>> of it.)
>> >>...we should estimate that there are >>significant more end users than there are authors. If there is really >>a trade-off between burdon for end users and burden for authors, then >>we should most often shift this burden on the author.
> > The end users still lose here waiting days for the author to fix the bug > introduced by M::B attempting to save a few bits and tics. > > I know it's saying "upgrade, upgrade", but really: how viable is it to > *not* upgrade M::B if authors (whose recently released modules are being > installed) are actively upgrading it and possibly using new features? > You're not getting configure_requires for a M::B which came out *after* > the module being installed, right? With all of this change, how long > will it take for a statically-coded value to cause a bug?
How long it will take? Longer than in your preferred model. The mathematical argument is easy. There are two versions of Module::Build, v1 and v2. We all know that both have bugs. You may be sure that the new version has less bugs than the old version. Fine. But no doubt the two versions will have a different set of bugs. Given p1 is the probability to be hit by a bug in v1 and p2 is the probability to be hit by a bug in v2. The user who is locked into only having access to v2, is a victim of a bug with probability p2. Users who have a choice between v1 and v2, have a workaround. If they are hit by a bug in v1, they can still try v2. They are victims of a bug only with the probability p3. How big is p3? If the set of bugs is completely independent of each other, the probability is p1*p2 which is considerably less than p2. If there is a common set of bugs it is still less than p2. And only if the bugs in v2 are a subset of the bugs in v1, then p3 equals p2. In all other cases it is lower. In other words, p3 is lower in the general case, and it is only in the worst case equal to p2. "Ken Williams via RT" <bug-Module-Build@rt.cpan.org> writes: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=58445 > > > On Wed, Sep 12, 2012 at 1:38 AM, (Andreas J. Koenig) via RT < > bug-Module-Build@rt.cpan.org> wrote: >
>> >> If one would code '0.40' there statically, nothing would change compared >> to status quo. And bumping that only once you know that '0.41' has had >> time to propagate and be widely deployed would solve my gripe. It would >> be a tiny bit less simple and huge amount less stupid. >>
> > Suppose we did that, imagine the breakage scenario. Suppose the author > installs 0.42 or 0.43, and we don't think they've propagated very far, so > the hard-coded value is still 0.40. Then if the author uses *any* features > that were added after 0.40, or exercises any code that was buggy in 0.40 > but fixed later, then this just BLOWS UP or WORKS WRONG on the end user's > machine. > > So the author, if he/she wants to be a responsible person and not risk > blowups, has to 1) go check what the hard-coded value is, and 2) figure out > what all these feature & bug changes are relative to their installed > version, and 3) not use them. So there was no point in upgrading in the > first place. So they should never upgrade. So we can never add new > features. So the project is essentially dead.
Setting up my wishful thinking hat, of course it would be wonderful if Module::Build could determine which features this (current) author is using and which features were fixed when exactly and determine the optimal version that this current distro should put into configure_requires. I don't expect that this will happen. That's why David suggests KISS which I agree with in principle. But I doubt his KISS is the right one. I for one prefer a choice for the end user. Locking them into a single version or making the choice for them hard needs deep justification in the very concrete case. If there is a huge and serious bug being fixed, I would agree that it makes sense to set configure_requires to the current version. But in the absence of overwhelming evidence it does no good to prevent choice. -- andreas
Subject: Re: [rt.cpan.org #58445] overzealous usage of configure_requires considered harmful
Date: Thu, 13 Sep 2012 01:13:59 -0700
To: bug-Module-Build [...] rt.cpan.org
From: Eric Wilhelm <enobacon [...] gmail.com>
Download (untitled) / with headers
text/plain 1.8k
# from (Andreas J. Koenig) via RT on Wednesday 12 September 2012: Show quoted text
>Setting up my wishful thinking hat, of course it would be wonderful if >Module::Build could determine which features this (current) author is >using and which features were fixed when exactly and determine the >optimal version that this current distro should put into >configure_requires. I don't expect that this will happen.
It could possibly be done iff every new feature in M::B was wrapped in (and only enabled by) an interface analogous to 'use feature ...'. That would be difficult to implement and maintain and authors might find it tedious to declare, in which case we're back to where we are now but out the effort and with more code to support. Show quoted text
>That's why >David suggests KISS which I agree with in principle. But I doubt his >KISS is the right one. I for one prefer a choice for the end user. >Locking them into a single version or making the choice for them hard >needs deep justification in the very concrete case.
The end user absolutely has a choice if they're really just trying to work-around a bug in the latest M::B's installation support (which should not be very often unless something needs to be fixed in the testing/release process.) Further, I don't think it is very complicated or difficult for anyone who is prepared to make that choice to also be able to access the knobs. What is the gain from running an older version? If there are problems with a newer version, what are the chances that no other module being installed requires the latest? It all seems like a lot of work and risk to enable users to avoid updating software while they're in the process of updating software. --Eric -- --------------------------------------------------- http://scratchcomputing.com ---------------------------------------------------
CC: ANDK [...] cpan.org
Subject: Re: [rt.cpan.org #58445] overzealous usage of configure_requires considered harmful
Date: Sat, 15 Sep 2012 07:50:17 +0200
To: bug-Module-Build [...] rt.cpan.org
From: Andreas Koenig <andreas.koenig.7os6VVqR [...] franz.ak.mind.de>
Download (untitled) / with headers
text/plain 2.6k
"Eric Wilhelm via RT" <bug-Module-Build@rt.cpan.org> writes: Show quoted text
> It could possibly be done iff every new feature in M::B was wrapped in > (and only enabled by) an interface analogous to 'use feature ...'. That > would be difficult to implement and maintain and authors might find it > tedious to declare, in which case we're back to where we are now but out > the effort and with more code to support.
We are in violent agreement on this one. This solution is far too complicated and most probably won't happen and is not the alternative I'm suggesting. Let's concentrate on KISS solutions. Show quoted text
>>That's why >>David suggests KISS which I agree with in principle. But I doubt his >>KISS is the right one. I for one prefer a choice for the end user. >>Locking them into a single version or making the choice for them hard >>needs deep justification in the very concrete case.
> > The end user absolutely has a choice if they're really just trying to > work-around a bug in the latest M::B's installation support (which > should not be very often unless something needs to be fixed in the > testing/release process.)
The end user has always "a choice". I'm reporting what has been encountered as an annoyance. See the subject line. Show quoted text
> Further, I don't think it is very complicated > or difficult for anyone who is prepared to make that choice to also be > able to access the knobs.
You seem to believe that end users who report an annoyance cannot be right because you have not yet encountered it. While it is fine for you, I find such an answer rather unconstructive. There are a few lines of code in Module::Build that do two things: (1) they considerably increase the probability that end users will unrightfully be told that they have to upgrade and (2) they increase the probability that the end user gets a not working environment. Case (2) has not yet happened but is mathematically provable, and (1) is the point I have encountered in numeroues cases and reported in this ticket. Show quoted text
> What is the gain from running an older version? If there are problems > with a newer version, what are the chances that no other module being > installed requires the latest? It all seems like a lot of work and risk > to enable users to avoid updating software while they're in the process > of updating software.
On the contrary. In the process of upgrading software we always are at risk from the very fact that we're doing it. So we are much better off when we get resilience in all dimensions of software development we have to deal with. Please remember, the real reason why the motto of perl is TIMTOWTDY is "because some of them do not work". Thank you very much. -- andreas


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.