On Mon, Jan 12, 2004 at 08:39:20PM -0500, David R. Morrison wrote: > Daniel Macks <[EMAIL PROTECTED]> wrote: > > > A possible solution would be to declare that any package that depends > > on a versioned module must be versioned. Period. It would therefore be > > installed in the versioned part of lib/perl5 and would have its > > dependencies on versioned packages. No "foo-pm580 provides foo-pm" and > > no boatload of unversioned placeholder bundles, so one cannot > > accidentally depend on a non-versioned thing that has a hidden > > versioned dependency at any depth. No problem with trying to install > > two versioned versions of the same perl module that conflict with each > > other. > > > > Unfortunately, we don't have complex boolean expressions so we can't > > Depends: perl, (perl560, a-pm560, b-pm560) | (perl 580, a-pm580, b-pm580) > > So for packages of scripts that need any versioned packages, just pick > > perl and use that version for all Depends. > > This would work pretty well, I think. However, there is another aspect > to the problem. Some pm packages install binaries in /sw/bin and/or > man pages in /sw/share/man. If you have different pmXXX packages, they > will want to install the same file.
Good point. It sounds like it's a given that the set of /sw/bin files is the same for each XXX (from a human or other public interface perspective; would obviously differ in #!/sw/bin/perlXXX). I can't think of a situation where one would need those files from more than one perl version installed at one time. > One short-term solution to this is to allow foo-pmXXX to replace foo-pmYYY > for all the other YYYs. That means one could never have more than one perl have a given module at a time. Not ideal at all--the logical extension is that one may only have one perl installed at once (which would also solve all our problems *G*). I'd have to defer to others who understand the dependency engine better, but what happens when one has installed foo-pmYYY and bar-pmYYY which depends on it, and then tries to install wocka-pmXXX which depends on foo-pmXXX? Does Engine.pm catch fire? What about putting the /sw/bin files into a foo-pmXXX-bin splitoff (and same for man into -doc), that each conflicts/replaces all other XXX? So now (again) an end user could just pick whichever one corresponds with his perl flavor, but could never have more than one installed at once. I like this because it keeps filesystem down, and also it feels familiar to packagers: it's essentially the same solution we currently have for shared library major-versions. > Another is to use the update-alternatives facility in fink. Also reasonable. Could perhaps work in conjunction with your next suggestion to allow control over which XXX binaries were prefered on a file-by-file basis, rather than "'all of XXX' before 'all of YYY'" which would result from PATH games. > A long-term way to address this would be to have separate bin and man > directories associated to each flavor of perl. I guess they could be > /sw/share/perl560/bin and /sw/share/perl560/man and so on. Then, we > could have the perl560 package put the appropriate things in the PATH. Would be simple to do, but no granularity and no (?) need for the "hidden" ones to exist at all. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks ------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
