Daniel Macks <[EMAIL PROTECTED]> wrote: [snip] > 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. > > There are more technical solutions involving changes to the fink code > or to dpkg, but this seems straightforward to implement (just a policy > change and then fix a bunch of packages instead of modifying fink and > waiting for fink-0.19.0 since the problem is here now and arising > often on #fink, -devel, and the trackers).
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. One short-term solution to this is to allow foo-pmXXX to replace foo-pmYYY for all the other YYYs. Another is to use the update-alternatives facility in fink. Both are awkward. 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. (This would need a change to fink: we can define the bin and man directories appropriately as the -pmXXX packages are being built, automatically.) -- Dave ------------------------------------------------------- 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
