On Mon, Jan 12, 2004 at 05:18:37PM -0500, Koen van der Drift wrote: > Hi all, > > I submitted a package to the tracker that is pure perl (gd-svg-pm), but > it depends on a versioned package (gd-pm). The package was not yet > moved to unstable because of an apparent problem with the versioning. > > I quote the comments on the tracker (from Dan Macks): > > "One could have gd-svg-pm installed, and gd-pm installed with > its dependencies satisfied by gd-pm581. But now gd-svg-pm *only* > works under perl 5.8.1 (since there's no gd-pmXXX for other > perls). (*) > > So you'll need to have a family of packages gd-svg-pm581 and > friends, each depending on the analogous gd-pmXXX. But that's > gonna suck because each will conflict with the others. > > I don't know the ideal solution here. Maybe have the meat of > this module in gd-svg-pm but split off gd-svg-pmXXX each that > depends on the main package and also the relevant gd-pmXXX > (but doesn't actually contain anything).Then one would install > gd-svg-pmXXX for whichever perl one wants." > > > (*) there is actually gd-pm for 560, 580 and 581, so I am not sure what > Dan meant here.
What I meant was no *installed* gd-pmXXX other than 581. 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). 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
