There is, if I'm not mistaken, a problem of correct deps for a multi-perl fink installation. Recall that some pm's (roughly, those installing a bundle) must have "Type: Perl x.y.z" in their info file, and be built with perlx.y.z, to be usable with perlx.y.z _ and those packages get a name like foo-pmxyz. If other, non-versioned, pm's have to Depend on those, one needs an additional package foo-pm (Type: bundle), so the dependency can get listed as just on foo-pm.
The problem is how to express correctly the dependency of foo-pm on the different foo-pmxyz's: the effect should be that foo-pm being installed is a certificate, for whatever perlx.y.z is running, that the corresponding foo-pmxyz is there (and not just some foo-pmx'y'z').
So here is a proposal:
We introduce for each xyz a package 'perlxyz_not' that conflicts with perlxyz (where perlxyz is _ like eg perl580 _ a package that basically just does "ln -fs `which perlx.y.z`%p/bin/perl" _ hence conflicts with all other perlx'y'z') and with system-perlxyz: then we can let all foo-pm depend on " perlxyz_not | foo-pmxyz " for all xyz.
This will require the user to install foo-pmxyz for all bundles foo-pm and all perl versions x.y.z he has installed _ but there are not that many bundles, and it seems a condition for a reliable system.
Note that the 'perlxyz_not' packages are not logically necessary in
this proposal, they are just a shorthand to simplify the writing of the
Deps in the foo-pm packages : else each 'perlxyz_not' in those Deps
should be replaced by the alternative that some other perlx'y'z' is installed.
The system has some defects: eg, a user who would not install
perlxyz, just perlxyz-core, and try to use that _ either by using explicitly
"perlx.y.z" as command or by doing "ln -s `which perlx.y.z`/usr/local/bin/perl"
would not be protected.
Also, I'm afraid manual intervention will be required eg when a
user, who has nothing of say perl580 installed, and hence has perl580_not
installed, issues 'fink install perl580' : the logic is that
- since the user explicitly asks to install a package that conflicts with perl580_not,
the latter package will have to go.
- since there is a legal way to satisfy the user's request without removing any other
package, that's what should be done
[ The legal way: 1) build perl580
2) install perl580-core 3) build and install in build-order all foo-pm580
for which foo-pm is installed 4) remove perl580_not 5) install perl580 ]
But I don't think fink or dpkg's dependency engines are capable of this (maybe apt-get ?), and some manual guidance will be required here..
Comments ? Improvements or other suggestions ?
Jean-Francois Mertens
------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
