[Exherbo-dev] The new MYOPTIONS

Ciaran McCreesh ciaran.mccreesh at googlemail.com
Thu Oct 23 08:11:14 BST 2008

I've got choices more or less done for Paludis now, so we can start
arsing around with MYOPTIONS. The way Paludis does choices is to have
three keys:

    * choices_key(), in the main api, exporting fancy choices info
    * raw_iuse_key(), in e/, currently also used for MYOPTIONS
    * raw_use_key(), in e/, for pbins and installed packages

It's now easy enough to add in something like a raw_myoptions_key() in a
format that doesn't have to have anything to do with raw_iuse_key().
We'd just have to extend the "make choices_key" logic a bit to check
a third key. The upshot being... We can invent a new format for
MYOPTIONS if we like.

Current discussion has been about something like:

        foo [[ annotations ]]
            blah [[ annotations ]]

To make exlibs easier, we'll support syntax like:


although I doubt that'll be used explicitly by developers much.

Are we happy with this?

Annotations-wise, we're looking at implementing option restrictions
('foo needs bar', 'foo and bar are mutually exclusive' etc) as
annotations. At what point do we want to signal an error if these
restrictions aren't met? The pretend phase?

Do we also want descriptions to go in annotations? If yes, just local
descriptions? Will we still have global descriptions?

Choices lets us do some fairly devious trickery with options. One idea
that comes to mind is 'rare' options. An option marked as 'rare'
could be treated as hidden except if the user has explicitly set it.
This means it won't clutter up --pretend --install output, whilst
giving us a mechanism of providing options that aren't useful to most
people. Is this something we might want?

Exheres-0 doesn't have IUSE defaults. We could stick those in via
annotations if there's demand.

slowtests... Currently paludis_options: is a magic internal that is
*not* mapped onto options in any kind of way. Exheres-0 packages will
show up with three paludis_options: choices, strip, split and
recommended_tests (0-based EAPIs have optional_tests instead). Maybe we
want slow_tests as a fourth paludis_options: value. But then we'd need
a way of knowing whether a package had slow tests (test for existence
of src_test_slow, using the phase cache?), and possibly a way of
knowing that it doesn't have recommended_tests (but no src_test doesn't
mean no tests). Do we also want to indicate that strip and split don't
make sense for some packages too?

Ciaran McCreesh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.exherbo.org/pipermail/exherbo-dev/attachments/20081023/1a1ef185/attachment.pgp>

More information about the Exherbo-dev mailing list