On Tue, Mar 28, 2006 at 02:22:05AM +0200, Max Horn wrote: > Hi folks, > > I was wondering: Is there any sane way to specify a "common" splitoff > for a package with variants?
There's no way to have a single .info that contains a splitoff that is "less varianted" than the parent. If a .info has splitoffs that are "more varianted" than the parent all those variants are built together with the unified parent. > Type: perl (...). But most files in the package (many many files, > which maybe take hours to compiler) are identical across all perl > versions, so it seems kind of a waste to keep two builds of them > around. So you would like to keep those files in a shared package. > > * Ignore that some stuff is common and simply have FOO-pmXXX w/o any > splitoffs -- after all, most users will build & install the package > once only anyway. So no need to worry about the common stuff. If a user "will build &install the package once only", then there's no "keep two builds of them around" problem. > * Make a FOO-common package with "FOO-pmXXX" splitoffs depending on > it. Problem: This enforces the dependencies of *all* variants to be > fulfilled (at least that's what trial&error tells me). In particular, > one has to install perl581-core to be able to build FOO-pm586 (at > least for me using Fink CVS from yesterday). Right. Varianted packages are full packages in their own right (contrary to how the .info looks, they're not a collection of subtypes of a master package). And "%n-%v-%f" is the unique identifier of a package. So if there is a varianted package as a splitoff of a common parent, there are really "several splitoff packages", exactly as if it were written as explicit and distinct SplitOff/SplitOff2/etc for each variant. > In addition to all this, the fact that there are some perl modules > used is in the end irrelevant for the users. They want FOO. They > don't care if it's perl 5.8.1 or 5.8.6. Hence, you want them to be > able to type "fink install FOO" and it does the right thing (the user > still has to pick which perl version to use, but that's OK). You > don't want your users to figure out that they have to install "FOO- > pm586" instead of "FOO". Are other packages going to want to access the perl modules directly? If not, localize the package for the expected system perl version with appropriate Depends, then move the perl modules into %p/lib/%n and adjust the package scripts to look there. > This latter issue could probably be solved by using a separate "FOO" > bundle package I guess. Is that the way to go, I wonder? That's a viable solution, with two implementations: the "common" files themselves in the varianted packages (which Conflicts/Replaces each other; similar approach as the yelp-viewer-* packages) or these files renamed to varianted names (hence no Conflicts) and update-alternatives used to make one of them (at the user's control) also available at the truly common name (see for example scipy-core-pyXX). dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
