Re: Versioned provides ... a necessity !
On Wed, 10 Feb 1999, Chip Salzenberg wrote:
> According to Jules Bean:
> > On Wed, 10 Feb 1999, Chip Salzenberg wrote:
> > > According to Jules Bean:
> > > > For their own reaons, which are opaque to me [but are almost certainly
> > > > documented somewhere - try perl5-porters] upstream has decided to change
> > > > the path-names. They've done this because they think most modules won't
> > > > continute to work, I imagine. So we shouldn't defy their policy.
> > >
> > > No; only the BINARY interface for shared libs has changed incompatibly.
> > > Any Perl-only module that's compatible with e.g. 5.004 should work
> > > without change under 5.005.
> >
> > In which case, there's no reason why we (debian, that is) shouldn't have a
> > shared lib directory between 5.004 and 5.005 (and 5.006...), is there?
>
> Well, that depends. Are you at all interested in having 5.004 and
> 5.005 coexist? If not, then: No, there's no reason not to just
> upgrade /usr/lib/perl in place.
The point is that if 5.004 and 5.005 coexist in our distribution, then it
doesn't matter if they coexist on a user's machine.
Currently, we have to repackage all our perl module packages, to move them
from /usr/lib/perl5 to /usr/lib/perl5/5.005. Even the ones which don't
need recompiling, need moving.
>
> > So we could move all our (non-binary) modules to a directory whose name
> > isn't going to change, and use it for subsequent versions.
>
> Yes.
Good. That's a start in the right direction.
>
> The 'upstream' policy from us perl5-porters is *not* that Perl
> versions _must_ coexist. The upstream policy is that the Perl
> distribution must _permit_ coexistence for those users who want it.
> (Perl isn't about forcing people to do things the 'right' way.)
*good* ;)
>
> But if you _are_ interested in coexistence, then I think you should
> also have /usr/lib/perl5.005 for 5.005's standard modules,
> /usr/lib/perl5.004 for 5.004's standard modules, etc. And also
> /usr/lib/perl5 for modules that work with any of the supported Perl
> version (5.004+, basically).
Looks sensible.
>
> You may want to consider putting all modules that aren't distributed
> with Perl into a directory separate from Perl's standard modules.
> That'll ease administration of Perl upgrades and other things.
Agreed there.
>
> > Modules which *do* in fact require a particular version (perhaps because
> > they use a new feature) could then be installed in the version specific
> > directory.
>
> Right.
>
> > Except then they won't be available in the next version.
>
> No help for that. You can't compile a .so against object files that
> don't yet exist. :-(
Not what I meant. As you observed, some non-binary modules *might* still
have a version dependence, even if most don't. Suppose I write
package Jules;
require version 5.005; # Is that how I write it? Doesn't matter..
Because Jules.pm relies on some feature or bugfix in 5.005. Now Jules.pm
can't go into 5.004, since it might then be run by a 5.004 perl process
causing an ugly mess. But, if it goes into 5.005, then I'm going to have
to provide a new version when 5.006 comes out.
Jules
/----------------+-------------------------------+---------------------\
| Jelibean aka | jules@jellybean.co.uk | 6 Evelyn Rd |
| Jules aka | jules@debian.org | Richmond, Surrey |
| Julian Bean | jmlb2@hermes.cam.ac.uk | TW9 2TF *UK* |
+----------------+-------------------------------+---------------------+
| War doesn't demonstrate who's right... just who's left. |
| When privacy is outlawed... only the outlaws have privacy. |
\----------------------------------------------------------------------/
Reply to: