As discussed by Dan Macks and myself on the submission tracker (for gd-svg-pm), I suggested the following for handling perl modules. Maybe it has been discussed previously, and there might be very good reasons why it won't work. Feel free to trash it, but be nice :)
Anyway, the idea is to only have info files that are named foo-pm, so no versioned packages, even for perl modules that don't need to be versioned. When a package needs to be installed, fink checks the perl version (XXX) on the system, and builds a package, that will be named foo-pmXXX.deb. So the user will end up with the correct version of foo-pm for the system just using one info file, and the deb files are distributable. All man files, scripts, etc will also end up in the correct place. If foo-pm depends on bar-pm, then bar-pm will first be installed as bar- pmXXX, etc. As suggested by Dan, the info file could have a line that informs if the package is incompatible with a certain version of perl.
- Koen.
On Jan 13, 2004, at 12:49 AM, Daniel Macks wrote:
On Mon, Jan 12, 2004 at 11:12:47PM -0500, David R. Morrison wrote:Daniel Macks <[EMAIL PROTECTED]> wrote:On Mon, Jan 12, 2004 at 08:39:20PM -0500, David R. Morrison wrote:
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.
That means one could never have more than one perl have a given module
at a time.
Not true. The most common way in fink that "replaces" is used is to have one package both conflict with and replace another package.
However, if I simply put "Replaces: bar" into foo.info (wihtout using
Conflicts), then when you install foo.info, dpkg will overwrite any files
of the same name which belong to bar.
I did this with a few of the pmXXX packages this morning: foo-pm560.info
got "Replaces: foo-pm581" whereas foo-pm581.info got "Replaces: foo-pm560".
This way, the binary files correspond to the most recently installed
version of the package.
I just tried this, and it breaks for package removal. I had two packages:
foo (replaces bar) the contained %i/bin/{foo,thingy} bar (replaces foo) the contained %i/bin/{bar,thingy}
Installing foo gives /sw/bin/{foo,thingy}. Then installing bar gives /sw/bin/{foo,bar,thingy}. Now removing bar removes /sw/bin/thingy.
Dpkg doesn't have a memory of what replaced what, so when the replacement thingy is removed it doesn't know to bring back the one that was replaced.
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
------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
