On Sunday, January 12, 2003, at 04:02 PM, Randal L. Schwartz wrote:
David> 2) By convention, the user-modifiable portion of the Fink treeYeah, that was my thought. =)
David> is /sw/etc. So I think we should create /sw/etc/perl/5.6.0 and
David> /sw/etc/perl/5.8.0 and symlink them back into the /sw/lib/perl
David> trees that we are making. That way perl finds them, but users
David> only write to /sw/etc.
Ick. Ick. ick ick.
If you want to do it "the perl way", /sw/lib/perl5/$version/ is for
core libraries, and /sw/lib/perl5/site_perl/$version/ is for
after-core add-ons. $version is 5.6.0 or 5.8.0 right now.
Don't put anything in /sw/etc/. Ick. These aren't config files. These
are libraries, installed using the normal means. People won't
be *editing* these, which is what I think of when I see /*/etc/.
Perl modules are *not* supposed to be user-modifiable. /sw/etc is definitely not the place for it.
David> 3) We are going to need separate Fink packages for 5.6 perl modules andI don't think that's a problem, it's mostly a matter of semantics.
David> 5.8 perl modules. We are going to need a way to build a 5.6 perl module
David> when 5.8 is installed, and vice versa. Seems to me that we'll probably
David> have binaries called /sw/bin/perl56 and /sw/bin/perl58, and that those
David> will be called by name when the perl module is compiled. (So these
David> packages may have "BuildDepends: perl56" or "BuildDepends: perl58".)
Again, the convention for this is that /sw/bin/perl should link
to the "active" perl. If anything is specific on a version number,
then they can link directly to /sw/bin/perl5.8.0 or /sw/bin/perl5.6.0
The thing that scares me even more is the earlier suggestions of "2 packages for everything". We stopped officially supporting 10.1 because we couldn't expect most maintainers to keep up with both, why would we expect every perl module maintainer to build a 5.6 and 5.8 version? What about when perl6 comes out and we now need to maintain 3 different perl trees?
Just managing the difference between kde's ssl and non-ssl versions is harrowing, and prone to drift. I can't imagine us having to do the same thing for 100 perl modules.
-------------------------------------------------------
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
