[Koha-devel] [Koha-patches] [PATCH] [Bug 5465] Makefile.PL asks for too high version of Business::ISBN

Clay Fouts cfouts at liblime.com
Thu Dec 2 17:48:31 CET 2010


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 at foundations.edu>

>  CC'ing the dev list....
>
>
> On Thu, Dec 2, 2010 at 11:16 AM, Liz Rea <lrea at nekls.org> wrote:
>    On Thu, Dec 2, 2010 at 9:39 AM, Chris Nighswonger <
> cnighswonger at foundations.edu> wrote:
>
>> On Thu, Dec 2, 2010 at 9:48 AM, Liz Rea <lrea at 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 at 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20101202/4ba4dca5/attachment-0001.htm>


More information about the Koha-devel mailing list