On Thu, Apr 08, 2004 at 11:39:56AM -0700, Remi Mommsen wrote:
> On Apr 8, 2004, at 11:07 AM, Daniel Macks wrote:
> >On Thu, Apr 08, 2004 at 10:30:18AM -0700, Remi Mommsen wrote:
> >>
> >>I'm trying to figure out how to use the variant system. I'd like to
> >>use it for roofitcore package, where the essential difference between
> >>roofitcore and roofitcore4 is the depenency on the root version (root3
> >>or root4). I'd like to have a statement similar to
> >>
> >>Depends: <<
> >> %N-shlibs (=%v-%r),
> >> (%type_raw[root_version] = 4) { root4 | root4-cernlib, root4-shlibs |
> >>root4-cernlib-shlibs }
> >> (%type_raw[root_version] = .) { root3 | root3-cernlib, root3-shlibs |
> >>root3-cernlib-shlibs }
> >><<
> >>
> >>However, AFAIK there is no support for having a block of dependencies
> >>for a given case.
> >
> >That's correct. Right now you would have to do the conditional for
> >each package:
> >
> >Depends: <<
> > %N-shlibs (=%v-%r),
> > (%type_raw[root_version] = 4) root4 | (%type_raw[root_version] = 4)
> >root4-cernlib,
> > (%type_raw[root_version] = 4) root4-shlibs | (%type_raw[root_version]
> >= 4) root3-cernlib-shlibs,
> > (%type_raw[root_version] = .) root3 | (%type_raw[root_version] = .)
> >root3-cernlib,
> > (%type_raw[root_version] = .) root3-shlibs | (%type_raw[root_version]
> >= .) root3-cernlib-shlibs,
> ><<
>
> Yep, that's what I suspected.
>
> >Are you stuck with 'Type: root_version (4 .)' or could you use (3 4)
> >instead? The latter would let you do
> >
> >Depends: <<
> > %N-shlibs (=%v-%r),
> > root%type_raw[root_version] | root%type_raw[root_version]-cernlib,
> > root%type_raw[root_version]-shlibs | root%type_raw[root_version]-cernlib-shlibs
> ><<
>
> That's a neat solution. However this would produce a package named
> roofitcore3 instead of roofitcore, isn't it?
Correct. I specifically made this easy to do, since it's in keeping
with fink shlib package naming policy. If there are going to be
multiple bar each the same but tied to a specific X of fooX it makes
some sense to have them as barX.
> No real problem as there is only one package depending on roofitcore
> which is going to be updated, too. However, it will break the
> automatic update for users having roofitcore installed.
If I understand correctly, the project at hand is to have a single
.info that gives roofitcore and roofitcore4 (both of which already
exist) and it would be a confusing upgrade because there would
suddenly be roofitcore3 in place of roofitcore?
> Thus I'm faced with the choice between a neat info file and a
> (minor) annoyance for (a few?) users. What's your opinion?
You could have (for a while) a roofitcore package that was just a
bundle for roofitcore3. That way when they update their roofitcore,
they wind up deleting their current roofitcore actual package and
getting on the versioned bandwagon. Or you could just dump roofitcore
altogether and have roofitcore[34] Conflicts/Replaces roofitcore (in
addition to each other as necessary). Users who have already installed
it won't be affected, since it's okay to have a package installed that
has no .info, but as soon as they want to update, 'fink list
roofitcore' will list the 3 and 4 variants.
dan
--
Daniel Macks
[EMAIL PROTECTED]
http://www.netspace.org/~dmacks
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel
