Re: [Koha-devel] [Koha-patches] [PATCH] [Bug 5465] Makefile.PL asks for too high version of Business::ISBN
CC'ing the dev list.... On Thu, Dec 2, 2010 at 11:16 AM, Liz Rea <lrea@nekls.org> wrote: On Thu, Dec 2, 2010 at 9:39 AM, Chris Nighswonger < cnighswonger@foundations.edu> wrote:
On Thu, Dec 2, 2010 at 9:48 AM, Liz Rea <lrea@nekls.org> wrote:
Backing down the version to 2.0301 to match the Lenny available package.
Hmm... 2.05 is the newest version of this module in cpan. I think Makefile.PL should always ask for what is truly the newest version rather than being tied to a particular distribution.
my $0.02 worth
Kind Regards, Chris
I did actually think about this before I did it. :)
I asked around if it would be better to update the documentation to take the package out of the install script and add it to the CPAN list, or do what I did, and the general consensus was that backing down the required version was a better option (since the newer version doesn't add any functionality that we actually use), so I did that.
The reason is that a lot of people use Lenny (and or Ubuntu, which would cause this same issue), and Squeeze/Sid aren't stable yet (even though they work fine, I know that). Every indication I've gotten is that "we" prefer packaged versions of things instead of pulling direct from CPAN. I chose to eliminate the error message when installing on Lenny/Ubuntu from Makefile.PL, and allow a required version that was lower than the current version to help eliminate a bad user experience (An error!!! OMG! What do I do!).
I truly don't care which way it's done: we can remove it from the package script and add it to the modules requiring installation through CPAN, no problem. I'll do those patches too, if necessary.
That said, I don't think the reasoning behind this particular patch is unsound, based on past precedent.
I'm not familiar with what has been the rule in the past. However, it is my opinion we should establish one standard rather than attempting to work around two different ones. If we are going to take the Debian/Ubuntu repo version as the standard, we should set all modules available in those repos to the max current version available in those repos, and be sure that policy is clear in the docs. We should also develop only over those currently available versions. (I realize in this particular case there is no programmatically compelling reason to use the latest version, but that is not always the case.) FWIW, I favor Debian/Ubuntu personally, but am concerned about this from a policy standpoint. If we indeed see this as the best direction to go, I recommend we add something like this to our coding guidelines: When/Where available, Koha Perl dependencies should be sourced from the current stable Debian/Ubuntu repository. Perl dependencies not available in the repository should be sourced from CPAN. Code development should be limited to the most current version available from the proper source. Exceptions to this policy may be made by gaining consensus from the developer section of the community. or some such language... Kind Regards, Chris
Le 02/12/2010 17:25, Chris Nighswonger a écrit :
I did actually think about this before I did it. :)
I asked around if it would be better to update the documentation to take the package out of the install script and add it to the CPAN list, or do what I did, and the general consensus was that backing down the required version was a better option (since the newer version doesn't add any functionality that we actually use), so I did that.
The reason is that a lot of people use Lenny (and or Ubuntu, which would cause this same issue), and Squeeze/Sid aren't stable yet (even though they work fine, I know that). Every indication I've gotten is that "we" prefer packaged versions of things instead of pulling direct from CPAN. I chose to eliminate the error message when installing on Lenny/Ubuntu from Makefile.PL, and allow a required version that was lower than the current version to help eliminate a bad user experience (An error!!! OMG! What do I do!).
you can count BibLibre in "we" : we prefer packaged versions, no doubts ! So ++ to your proposition to have the oldest version that works fine required !
-- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
Le 02/12/2010 17:28, Paul Poulain a écrit :
Le 02/12/2010 17:25, Chris Nighswonger a écrit :
I did actually think about this before I did it. :)
I asked around if it would be better to update the documentation to take the package out of the install script and add it to the CPAN list, or do what I did, and the general consensus was that backing down the required version was a better option (since the newer version doesn't add any functionality that we actually use), so I did that.
The reason is that a lot of people use Lenny (and or Ubuntu, which would cause this same issue), and Squeeze/Sid aren't stable yet (even though they work fine, I know that). Every indication I've gotten is that "we" prefer packaged versions of things instead of pulling direct from CPAN. I chose to eliminate the error message when installing on Lenny/Ubuntu from Makefile.PL, and allow a required version that was lower than the current version to help eliminate a bad user experience (An error!!! OMG! What do I do!).
you can count BibLibre in "we" : we prefer packaged versions, no doubts ! So ++ to your proposition to have the oldest version that works fine required !
I agree with that. But then we have to be quite specific then about the OS we support Redhat Fedora, CentOS, debian, ubuntu donot have the same standard as of perl module packaging. Or should we try and maintain packages for all the versions ? -- Henri-Damien LAURENT
On Thu, Dec 2, 2010 at 3:09 PM, LAURENT Henri-Damien < henridamien.laurent@biblibre.com> wrote:
Le 02/12/2010 17:25, Chris Nighswonger a écrit :
I did actually think about this before I did it. :)
I asked around if it would be better to update the documentation to take the package out of the install script and add it to the CPAN list, or do what I did, and the general consensus was that backing down the required version was a better option (since the newer version doesn't add any functionality that we actually use), so I did that.
The reason is that a lot of people use Lenny (and or Ubuntu, which would cause this same issue), and Squeeze/Sid aren't stable yet (even though
work fine, I know that). Every indication I've gotten is that "we"
Le 02/12/2010 17:28, Paul Poulain a écrit : they prefer
packaged versions of things instead of pulling direct from CPAN. I chose to eliminate the error message when installing on Lenny/Ubuntu from Makefile.PL, and allow a required version that was lower than the current version to help eliminate a bad user experience (An error!!! OMG! What do I do!).
you can count BibLibre in "we" : we prefer packaged versions, no doubts ! So ++ to your proposition to have the oldest version that works fine required !
I agree with that. But then we have to be quite specific then about the OS we support Redhat Fedora, CentOS, debian, ubuntu donot have the same standard as of perl module packaging.
This is my only fear. If we stray too far into specifying *which* OS we will support, unforeseen problems could arise. And we begin introducing restrictions. However, regardless of the direction we take, we should standardize and state it so that we have a consistent understanding among developers.
Or should we try and maintain packages for all the versions ?
Ich... I think this would be a pit into which we would not want to fall. Kind Regards, Chris
Then I make a formal proposal that as a community we have an understanding of the following guidelines: For Debian and Ubuntu, we prefer to suggest/use packaged versions (if they are adequate) for the latest stable version of the OS at the time of release. Other dependencies that do not have packages or the packaged version is inadequate can be retrieved from CPAN, and the documentation will note which they are. Required versions should be the lowest version that allows all Koha functionality. It is the responsibility of the person adding an enhanced functionality to up the required version number when necessary. Other OS's are supported with dependencies coming from CPAN or packages/RPM's for that distribution, assuming they meet the version requirement. What do you think? Liz Rea NEKLS On Dec 2, 2010, at 2:09 PM, LAURENT Henri-Damien wrote:
Le 02/12/2010 17:28, Paul Poulain a écrit :
Le 02/12/2010 17:25, Chris Nighswonger a écrit :
I did actually think about this before I did it. :)
I asked around if it would be better to update the documentation to take the package out of the install script and add it to the CPAN list, or do what I did, and the general consensus was that backing down the required version was a better option (since the newer version doesn't add any functionality that we actually use), so I did that.
The reason is that a lot of people use Lenny (and or Ubuntu, which would cause this same issue), and Squeeze/Sid aren't stable yet (even though they work fine, I know that). Every indication I've gotten is that "we" prefer packaged versions of things instead of pulling direct from CPAN. I chose to eliminate the error message when installing on Lenny/Ubuntu from Makefile.PL, and allow a required version that was lower than the current version to help eliminate a bad user experience (An error!!! OMG! What do I do!).
you can count BibLibre in "we" : we prefer packaged versions, no doubts ! So ++ to your proposition to have the oldest version that works fine required !
I agree with that. But then we have to be quite specific then about the OS we support Redhat Fedora, CentOS, debian, ubuntu donot have the same standard as of perl module packaging. Or should we try and maintain packages for all the versions ? -- Henri-Damien LAURENT _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Typically they're called "requirements" because they establish a minimum. If a particular version is known to work and passes the tests, why require a system to have a higher version installed? Why instruct users to install from apt at all if they're just going to have to update all the modules from CPAN anyway? Why warn them they *need* to upgrade if in reality they don't? Issuing a warning during the build process should indicate something potentially dire, not making noise about a preference. Regards, Clay 2010/12/2 Chris Nighswonger <cnighswonger@foundations.edu>
CC'ing the dev list....
On Thu, Dec 2, 2010 at 11:16 AM, Liz Rea <lrea@nekls.org> wrote: On Thu, Dec 2, 2010 at 9:39 AM, Chris Nighswonger < cnighswonger@foundations.edu> wrote:
On Thu, Dec 2, 2010 at 9:48 AM, Liz Rea <lrea@nekls.org> wrote:
Backing down the version to 2.0301 to match the Lenny available package.
Hmm... 2.05 is the newest version of this module in cpan. I think Makefile.PL should always ask for what is truly the newest version rather than being tied to a particular distribution.
my $0.02 worth
Kind Regards, Chris
I did actually think about this before I did it. :)
I asked around if it would be better to update the documentation to take the package out of the install script and add it to the CPAN list, or do what I did, and the general consensus was that backing down the required version was a better option (since the newer version doesn't add any functionality that we actually use), so I did that.
The reason is that a lot of people use Lenny (and or Ubuntu, which would cause this same issue), and Squeeze/Sid aren't stable yet (even though they work fine, I know that). Every indication I've gotten is that "we" prefer packaged versions of things instead of pulling direct from CPAN. I chose to eliminate the error message when installing on Lenny/Ubuntu from Makefile.PL, and allow a required version that was lower than the current version to help eliminate a bad user experience (An error!!! OMG! What do I do!).
I truly don't care which way it's done: we can remove it from the package script and add it to the modules requiring installation through CPAN, no problem. I'll do those patches too, if necessary.
That said, I don't think the reasoning behind this particular patch is unsound, based on past precedent.
I'm not familiar with what has been the rule in the past. However, it is my opinion we should establish one standard rather than attempting to work around two different ones.
If we are going to take the Debian/Ubuntu repo version as the standard, we should set all modules available in those repos to the max current version available in those repos, and be sure that policy is clear in the docs. We should also develop only over those currently available versions. (I realize in this particular case there is no programmatically compelling reason to use the latest version, but that is not always the case.)
FWIW, I favor Debian/Ubuntu personally, but am concerned about this from a policy standpoint.
If we indeed see this as the best direction to go, I recommend we add something like this to our coding guidelines: When/Where available, Koha Perl dependencies should be sourced from the current stable Debian/Ubuntu repository. Perl dependencies not available in the repository should be sourced from CPAN. Code development should be limited to the most current version available from the proper source. Exceptions to this policy may be made by gaining consensus from the developer section of the community.
or some such language...
Kind Regards, Chris
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
On Thu, Dec 2, 2010 at 11:48 AM, Clay Fouts <cfouts@liblime.com> wrote:
Typically they're called "requirements" because they establish a minimum. If a particular version is known to work and passes the tests, why require a system to have a higher version installed?
This most likely occurs because the developer adding the module develops over the latest module from CPAN rather than from xyz repository which may be behind CPAN. I think it would be poor practice to expect developers to hunt for the oldest package which contained the desired functionality. It would be better to adopt a sensible standard and adhere to it, which is what I was proposing we do.
Why instruct users to install from apt at all if they're just going to have to update all the modules from CPAN anyway?
Users are only instructed to install from apt on platforms which support apt. Others should use their distro's package management system or CPAN... which is what gives rise to the "problem" under discussion.
Why warn them they *need* to upgrade if in reality they don't?
"Needing" to upgrade is relative. In this case relative to the version required by the developer incorporating the module and thus Koha. If the user's system has a version older than that required by the developer, there is certainly the "need" to upgrade.
Issuing a warning during the build process should indicate something potentially dire, not making noise about a preference.
Given that it is the developer who writes the code involving a selected module, I think that this is not a mere "preference" of the developer. The one developing knows better than anyone else which version is "needed." Using a module version other than that spec'd by the developer is, indeed, setting up for something potentially dire. There are two points involved here: 1. We need to establish acceptable guidelines for developers to follow when choosing packages. 2. We then need to communicate the clear message to the user that they need *at least* the version chosen by the developer. Then the warnings thrown will be unambiguous. (And I'm assuming here that "we" feel they are ambiguous as they stand at present.) Kind Regards, Chris
Hi, On Thu, Dec 2, 2010 at 4:11 PM, Chris Nighswonger <cnighswonger@foundations.edu> wrote:
I think it would be poor practice to expect developers to hunt for the oldest package which contained the desired functionality. It would be better to adopt a sensible standard and adhere to it, which is what I was proposing we do.
There's no harm if a developer who adds a new Perl module dependency had simply used the latest and greatest, but there's also no harm if somebody points out that an earlier version of the module can serve the needs of Koha just as well. Ideally, Koha's test cases will help bolster a decision to change a version requirement with evidence. Since it's a fact of life that different distributions are more or less conservative about how frequently they update packaged Perl modules, I think we ought to be a bit more flexible and accept that sometimes a minimum required version can be decreased. At least we can be grateful that, as far as I know, we don't have a situation where we need to specify a *maximum* required version for any of Koha's dependencies. Regards, Galen -- Galen Charlton gmcharlt@gmail.com
participants (6)
-
Chris Nighswonger -
Clay Fouts -
Galen Charlton -
LAURENT Henri-Damien -
Liz Rea -
Paul Poulain