I was originally looking at something like this and I have thought a lot
about it, one of the main reasons to use xml for a new format was the
necessary complexity.
On Friday, January 18, 2002, at 02:48 , Max Horn wrote:
> So, regardless which format we choose, we want to support package
> variants. The question is, how to do it best.
>
> There are multiple ways to go at it:
>
> 1) Have variants like we have now, with explicit names:
> * a "default" variant
I would suggest something like:
<package name="foo" version="1.0.1" revision="1">
<depends/>
<compilescript/>
...
<variant name="ssl">
<depends/>
<compilescript type="replace">
</compilescript>
...
</variant>
<variant name="x">
<depends/>
<compilescript type="diff">
</compilescript>
...
</variant>
</package>
> * a "ssl" variant
> * a "nox" variant
> * a "ssl-nox" variant
>
Instead use variant x, and have the default no x, no ssl, etc.
> 2) Allow "options" that can be combined at will:
> * the base settings, no options
> * "ssl" - will enable ssl support
> * "nox" - will build without X11
> * "nognome" - will build without
>
Like above, I recommend that we ask the user what they want, then
specifically enable features, like variants of x, gnome, ssl.
>
> 1) obviously has the drawback that if you have 4 options to toggle, you
> have to list 16 varianst - ouch
>
> 2) is far more flexible, but what if we have options that contradict
> each other somehow? We'd need a way to specify that a certain option
> can't go with another one.
<require type="conflicts" package="" variant="x"> for a variant in the
same package
<require type="conflicts" package="bar" variant="x"> for a variant in a
different package
>
> Also, for 2), I don#t like to much the "nox" and "nognome" thingy,
> that's sort of double negation - no I do not want no X-Window support,
> ouch. So for 2, I'd imagine that we also provide a default set of
> options, so that could be a list like "DefaultOptions: x, gnome" or so.
>
Not me neither! ;-)
>
> In either case, I also imagine the whole thing to use, to speak in OOP
> terms, inheritance. What do I mean with this? Let's look at this
> example (in pseudo code):
>
> Package: foo
> Version: 1.0
> Revision: 1
> ConfigureParams: --with-gargle-blaster
> Depends: bar
> DefaultOption: x11
> Option: ssl
> ConfigureParams: --with-ssl
> Depends: openssl
> Option: x11
> ConfigureParams: --with-x
> Depends: x11
>
>
> So, in all cases, the "bar" package is a dependency, and the
> "--with-gargle-blaster" is passsed to configure.
> Now, there is a fundamental problem with this: what if a variant needs
> to *remove* something from the default set? Ohm, not good. So, why not
> use an if-else-approcah: Each variant doesn't just specify things for
> when it is specified, but also a list of things to do when it is not
> given. Look at this:
>
>
> Package: foo
> Version: 1.0
> Revision: 1
> ConfigureParams: --with-gargle-blaster
> Depends: bar
> DefaultOption: x11
>
> Option: ssl
> Depends: openssl
> NotOption: ssl
> ConfigureParams: --without-ssl
>
> Option: x11
> Depends: x11
> NotOption: x11
> ConfigureParams: --without-x
>
> Option: gnome
> ImpliesOption: x11
> ConfigureParams: --with-panel
> Depends: gnome
> NotOption: gnome
> ConfigureParams: --without-gnome
How about instead of ImpliesOption,
<depends>
<require type="depend" variation="x11"/>
</depends>
>
> NotOption: japanese
> ConfigureParams: --without-japanese
>
>
> Get what I mean? Note that the option "gnome" implies the option "x11".
> I am not sure how much sense I make, and there are probably holes in my
> thoguhts, so feel free to point them out :)
>
>
> Now the next step. How does a user specify options?
> Mabye like configure does:
> fink install foo --with-gnome --with-japanese
> Or like the current way:
> fink install foo-gnome-japanese
> Or maybe completly different
> fink install foo (gnome, japanese)
>
How about this?
fink install foo
Use x11? [y/N] y # Chose the default based on if
dependancies are filled.
This will require installation of one of the following
1) xfree86 # this is if we decide to merge
the packages
2) xfree86-system
3) xfree86-itools
Which one? (Enter 0 to choose not to install) [1] 1
Use gnome? [y/N] n
Use ssl? [Y/n] y
Installing xfree86...
[snip]
Though for many options, this could get tedious
>
> And how do we map all this to dpkg names? One way would be to take the
> list of options, sort them alphabetically, and add concat them with the
> package name using "-".
> So the above examples would result in the .deb for
> foo-gnome-japanese-x11
I agree, that would work, but the binary dist should only include the
default variety, although if others were requested a lot, they might be
added.
>
> What do you guys think? Am I crazy? :)
Not really :-)
However, whatever we do, the variety featureset is going to need a lot
of new code.
And I AM volunteering to do some of the coding, as long as I don't get
too deep in over my head. I'm familiar with advanced OOP, but I'm not
done figuring out the full Perl syntax yet, so I hope I can help!
>
>
> Max
> -- -----------------------------------------------
> Max Horn
> Software Developer
>
> email: <mailto:[EMAIL PROTECTED]>
> phone: (+49) 6151-494890
>
> _______________________________________________
> Fink-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/fink-devel
_______________________________________________
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel
