Front page | perl.perl5.porters |
Postings from October 2003
Re: Hidden dependencies?
Thread Previous
|
Thread Next
From:
Andy Dougherty
Date:
October 3, 2003 11:15
Subject:
Re: Hidden dependencies?
Message ID:
Pine.SOL.4.53.0310031403001.7206@maxwell.phys.lafayette.edu
On Fri, 3 Oct 2003, Sam Vilain wrote:
> On Thu, 02 Oct 2003 20:37, Andy Dougherty wrote;
>
> > Still, if someone wants to generate *and promise to maintain* such
> > scripts for various distributions, I have no philosophical
> > objection to including them in some sort of contrib/ directory in
> > the perl source. However, I wouldn't advise anyone to make such a
> > promise. Here's one good reason why: Perl releases occur
> > infrequently. Suppose such a script had been included in 5.8.0.
> > Would it have been reasonable to assume that distribution
> > packaging policies and expectations for all the included scripts
> > would not change in the 14 months between the release of 5.8.0 and
> > 5.8.1? I really doubt it.
>
> That sounds like the argument of a Debian developer ;). It doesn't
> need to conform to every single section of the full specifications,
> guidelines and other anal retention particular to the target
> distribution. You're not targeting debian, you're targeting `a dpkg
> based system'.
I disagree. To take a specific example: If perl-5.10.0 includes an RPM
'spec' file, and a RedHat user uses it to install perl-5.10.0, and that
installation breaks something in the RedHat system because the 5.10.0 spec
differs in some way from the "official" RedHat spec, who do you think will
end up dealing with the bug report?
> > As a final source of confusion, the infrastructure surrounding
> > such control scripts must be able to handle at least these two
> > separate cases correctly:
> > 1. The user wishes to *replace* the existing perl distribution.
>
> This would be the default; blend in as a part of the OS. For System
> V, the default would probably be to put itself in /opt/CPANperl or
> suchlike.
Here again, I disagree -- note the current default setting of
installusrbinperl ! But, more to the point, the fact that reasonable
people can and do disagree about whether this ought to be the default only
underscores how carefully one must tread.
> > That's hard to do well.
>
> Maybe, but the number of contributors and the length of time to the
> next release should get around that.
Time will tell. As I said, I have no philosophical objection to including
such contributions, if anyone really wants to make the commitment to
generate and maintain them.
--
Andy Dougherty doughera@lafayette.edu
Thread Previous
|
Thread Next