Kyle Moffett wrote:
> On Monday, October 7, 2002, at 08:04 PM, Max Horn wrote:
>> Nonsense. It is no problem at all to encode variants in the current
>> .info format. This has been discussed a lot in the past.
> It is not a problem, but it is somewhat clumsy, and I believe that a
> well designed XML format would make the documents easier to work with,
> especially as they get more complex. Even if we don't switch to an XML
> format, I would advise that we choose a similar form of document.
The last time the XML .info files argument came up, the main argument
against XML is that it's quite noisy compared to the current format. I
don't see what's wrong with
Variant: <<
Name: ssl
Description: Allows foo to communicate securely over the net.
With: <<
AddDepends: openssl
AddConfigureParams: --with-ssl
<<
Without: <<
Default: true
AddConfigureParams: --without-ssl
<<
<<
Can our .info parser handle that kind of heredoc syntax?
>> The real problem is the binary side, dpkg has no support for variants.
>> So we either give all the possible variants the same dpkg name or we
>> need to somehow map pkg+variant to a .deb file name. Both approaches
>> have deep problems.
> I fail to see the problem with sorting the variant names alphabetically
> and appending them on to the package name (IE: 'python-nox-ssl'). That
> way even bindist users could use different variants. (Important for ssl
> variants)
I think it would be best to include in the name each choice taken, to
make it perfectly clear what the package is. Also it would be good to
explicitly separate the variants from the name. So if we have variants
"gnome", "kde", "x11", "ssl" and splitoffs "dev", "shlibs", packages
could be named:
foo--gnome-nokde-nossl-x11
foo-shlibs--nognome-kde-nossl-nox11
Note the use of a double-dash to separate out the variants. Obviously,
users will generally not use these names, Fink should auto-generate
global foo, foo-dev, foo-shlibs packages that depend on the variants.
Then we can offer the choice of options, maybe something like this:
> % fink install foo
>
> ...
>
> Package foo can be built with these options:
> 1. gnome
> 2. kde
> 3. ssl
> 4. x11
>
> List the options you want to build with [1 2 3 4]: 1 2 4 <CR>
>
> Building foo--gnome-kde-nossl-x11...
The big problem with all this is getting all the dependencies sorted
out. For example, xchat can't take the --with-panel option unless it
also has --with-gnome. Also, sitecopy--ssl would depend on
neon-shlibs--ssl. But of course that could be satisfied with
neon-shlibs--blah-ssl or neon-shlibs--noblah-ssl.
This could all be handled via the creation of appropriate auxiliary
packages with the right dependencies--I did some testing once, apt can
handle the complicated dep. tree that results. Unfortunately, fink
probably can't, so we'd need both specific code to handle variants, as
well as a better general dependency resolver.
(Re the suggestion from earlier on that we adapt the libapt dep.
resolver: Apt and fink make different assumptions about what some
constructs should mean. For example, 'Depends: foo | bar'. Fink thinks
this means that either are equally good choices, ask the user. Apt
thinks it means that any of those are ok if they're installed--but if
not, install the first one possible. Similarly with virtual package
provides. So we either have to write a separate fink dep. resolver,
modify the apt code, or change fink's behavior.)
Some possibilities with variants that could be interesting:
* An "opt" variant could add optimization flags, or a "debug" one could
add debugging info. This is much safer than globally modifying CFLAGS,
since only packages that have been tested with optimization will have
an opt variant.
* Global variants and variant preferences would be nice. A
/sw/etc/variants that listed
gnome: yes
kde: no
ssl: ask
opt: default
*: default
would tell Fink to assume values for gnome and kde, ask about ssl every
time, and just use the default setting for opt and all others.
Alright, that's enough ranting for today.
Dave
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel
