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 > <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"> 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. [...] >How about instead of ImpliesOption, That was just a quick hack, never meant for real use :) ><depends> > <require type="depend" variation="x11"/> ></depends> Sure, although I don't see what purpose the outer <depends> element serves. > >> >>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... >>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). >>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. 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
