On Sunday, January 12, 2003, at 12:49 PM, David R. Morrison wrote:
A couple of comments on this thread:
1) Fred Sanchez wrote a revised darwin.sh for perl in the fall, which was
accepted into the perl tree. I believe that it essentially implements
what Chris did. We should follow it. (Links to the document were in my
previous post.)
Cool, I didn't know about Fred's work. I'll have to look at that.
2) By convention, the user-modifiable portion of the Fink tree is /sw/etc.I agree with Randall that this is not a good idea. While it may differ from standard perl, I prefer what I stated earlier:
So I think we should create /sw/etc/perl/5.6.0 and /sw/etc/perl/5.8.0 and
symlink them back into the /sw/lib/perl trees that we are making. That
way perl finds them, but users only write to /sw/etc.
/sw/lib/perl5/$version/ - core perl modules
/sw/lib/perl5/fink_perl/$version/ - fink-installed perl modules
/sw/lib/perl5/site_perl/$version/ - user-installed perl modules
This has the advantage that directory heirarchy for the core and user perl modules are exactly as they would be on Linux, BSD, etc. The fink_perl would be the exception from the norm, but IMO, that's OK because fink IS the exception from the norm.
However, I will happily defer to better ideas from Randall. :-)
3) We are going to need separate Fink packages for 5.6 perl modules andNo, as Randall said, the default perl install already creates these with the full version number. The one questionable thing is whether /sw/bin/perl should be created or not. IMO, it should be like ccache: it only overwrites the big one (cc in cccache's case, perl in perl5.8.0's case) if the user agrees. And, to preempt another possible discussion, /usr/bin/perl should *not* be touched at all, except by the user him/herself. We agreed on that latter point many months back.
5.8 perl modules. We are going to need a way to build a 5.6 perl module
when 5.8 is installed, and vice versa. Seems to me that we'll probably
have binaries called /sw/bin/perl56 and /sw/bin/perl58, and that those
will be called by name when the perl module is compiled. (So these
packages may have "BuildDepends: perl56" or "BuildDepends: perl58".)
You might have a "jumbo" perl mod package for Fink which built both a 5.6Maybe... But that would depend on both and removal would get nasty. It would have to be a virtual package which simply depended on both the 5.6.0 and 5.8.0 versions of the module.
version and a 5.8 version, so that whichever perl the user was using,
he or she got the correctly compiled module.
In general, though, I think that we may simply have to have multiple versions of every module. I don't think that's entirely a bad thing. Presumably, it will be minimal work for a maintainer to do both, since for most modules the only change will be to replace some 6s with some 8s. And if the module does change more significantly than that, well, then we did indeed need to have multiple versions of the .info file.
Or perhaps there should be a way for .info files to depend on each other? *cringe*
Chris
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel
