On Mon, Sep 27, 2004 at 11:36:01AM +0200, Michal 'hramrach' Suchanek wrote: > On Sun, Sep 26, 2004 at 09:08:26PM -0400, Daniel Macks wrote: > > On Sun, Sep 26, 2004 at 11:59:02PM +0200, Michal 'hramrach' Suchanek wrote: > > > > > > With the variant mechanism (which is new to me) one can make > > > conditional BuildDepends and check if the crypto extension should be > > > removed in the BuildScript. > > > > Why would you have separate -ssl and non-ssl variants and also a -ssl > > splitoff? If one has chosen the -ssl variant, then it is obvious that > > one wants -ssl functionality so I don't see why you would want to > > offload the -ssl stuff into a separate (optional plugin?) package. If > > one later changes one's mind about the presence/absence of crypto > > stuff, one just compiles and installs the ogther variant (which > > replaces the existing one). > > The ssl stuff is isolated in a plugin that can be installed/removed > separately and the rest of the package is the same both for crypto and > non-crypto. So I think it is useless to reinstall all the packages when > the only thing that is needed is to add/remove a single module.
Is it possible to compile the ssl component separately, or must it be compiled as part of the whole ruby package? If the former, then you could have the ssl-agnostic package and the -ssl plugin as two independent packages (distinct .info files): user would always use the ruby pkg, and then maybe add the -ssl plugin package. This sounds like what you are trying to accomplish. If you cannot "just" compile the -ssl stuff, you could still have the independent -ssl pkg. Have it compile the whole thing, but then only install the -ssl plugin stuff. This seems a waste of CPU cycles, but would prevent having two huge packages that differ only in the presence of a file or two. > > > How is the correct variant going to be selected if user requests one of > > > the packages that are common for both variants (ie ruby)? > > > > Fink's internal database is keyed by %n-%v-%r, so if there are > > multiple occurances all but one will get lost. That means you cannot > > have a common package as a splitoff of more than one package. > > So it may happen that fink chooses to build the non-ssl package to get > ruby and then the ssl package to get the ssl plugin if that is > requested? Except fink could get confused here, since the ssl plugin is a child of the ssl ruby, but if the ruby pkg that's in the database is the non-ssl one, the ssl package would not get built. Or the ssl pkg may appear as as child of the non-ssl ruby, in which case building will crash when it tries to move the non-existent ssl files into the splitoff? I don't completely understand all of the database inter-relationships... > As it is now I have both info files available and fink does always > choose the ssl info, possibly because it was indexed earlier/later. Yup. The order is based on the order the .info are processed, which is solely controled by the user. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
