At 17:08 Uhr -0500 18.01.2002, Kyle Moffett wrote:
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/>
How exatly do you intend the depends field to work? You only give empty examples
Sorry, this was just a kind of thinking out loud email, improving as I went along, and really, whatever format we choose ought to be reviewed here before anything solid is decided.
<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.
What I think.
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
"package" could be an optional attribute and left away, the same for variant. So that one can write <require type="conflicts" variant="x"/> or <require type="depends" package="bar">
That was implied, in fact, in XML::DOM, if an attribute requested is missing, undef is returned.
Hm, above you mention a <depends> element, now you use <require type="..."> - a good example of clash of different "believes" how XML should be used :) Compare the following three examples, all meant to represent the same:
1)
<require type="depends" variant="x"/>
<require type="depends" package="bar" before-version="2.0"/>
2)
<depends variant="x"/>
<depends package="x" before-version="2.0"/>
3)
<depends>
<package variant="x"/>
<package before-version="2.0">bar</package>
</depends>
(I meant before-version="2.0" to act the same as the current <<2.0 notation)
So, which one of these is "best" ? In my eyes, all have some pros and cons. Not an easy decision. But what I find important is that we try to use a single style throughout.
I definitely agree, and as above, whatever is chosen should be reviewed carefully, because we'll be stuck with it.
[...]
How about instead of ImpliesOption,
That was just a quick hack, never meant for real use :)
Same as most of the examples in my email, except they were in a different style of pseudo-code ;-)
<depends>
<require type="depend" variation="x11"/>
</depends>
Sure, although I don't see what purpose the outer <depends> element serves.
Just one more thing to complicate coding, of course! :-)
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
Yes. That's why I would prefer a "default configuration". Or maybe an option that determines whether fink asks you or just uses the default...
Or, how about:
fink install foo by default, will automatically use as many varieties as dependencies allow, or, <variety name="letter" default="true/> would cause that variety to be included in the default varieties. Not to be confused with the unnamed variety, which just has no extra options.
fink install foo -ask would ask for options, as above.
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.
Sure, this wouldn't be such a big problem in fact (not counting compile & upload time now, but that's an entierly different matter).
Especially using the naming scheme you suggested
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.
Yes and now, maybe not as much as you think.
This is not really much different from the current situation where we have say a "wget" and a "wget-ssl" package. Technically, it would be possible to take a single new-style package and convert it into multiple old-style packages which would be functionaly identically.
But still, it definitly is quite a sizeable task!
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!
Sure, any help is appreciated. We are still at the design stage of course, but I consider that to be extremly important. The best implementation is worthless with a bad design.
By the way, I currently have a mostly working xml interpreter using XML::DOM (aka xml-dom-pm that we could use for nonvariety (aka oldish format) xml documents. not much, but it's a start
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
