RE: [gentoo-dev] New system to replace USE flags

[Sean Mitchell]

Hi Dan....

A couple thoughts....

It seems to me that this system is too centralised. Someone is going to have
to maintain all the WITH variables in CVS and this also creates a
possibility of changes to that file impacting many ebuilds. Also, there is a
certain amount of duplication in intent between WITH variables and USE
variables, as shown in your example with QT. QT seems to be both a USE
variable and a WITH variable defined in two separate files.

Why not keep WITH variables local to the ebuild file itself? I think this
would have several advantages despite putting a certain amount of work back
onto the ebuilder. I think it would be easier to implement and manage.
Ebuild wouldn't need to be changed as much; it would only involve adding an
interact() function that asked the questions and then set the variables to
be used downstream. This would even reduce the work in upgrading existing
ebuilds if WITH variables can just update (locally) the value of a USE
variable. There doesn't seem to be much benefit to having a central list of
these WITH variables and in somes ways they seem to overlap the purpose of
USE variables.

I think the biggest use of these would be to (a) override a USE variable (b)
specify which of several conflicting USE variables to use, and (c) to
provide one-off configuration options.

I do like the idea of presenting a list of mutually exclusive options along
with a blurb about how to use them. There are lots of cases where you need
to choose which library or option you want and your choices may not be
consistent across packages. The idea of defining such a list as a group and
then specifying that group as the USE works well too.

Basically I think that WITH variables should be locally defined or
overridden USE variables, and treated just like USE variables once inside
the current standard ebuild functions. All we would need is another function
that can be triggered (interactive()?) to go through the list of WITH
variables, define them according to the user's preferences, and set them as
USE variables. The definition system you propose is fine and those
definitions would just be stored in a section of the ebuild. 

Cheers,

Sean

------------------------------------------------------------------------
 Sean Mitchell                                        Software Engineer
 smitchell@×××××××××××××××××××.com       Phoenix Interactive Design Inc
 tel. [phone] x237                        4th Floor, 137 Dundas St
 fax. [phone]                          London, ON, Canada  N6A 1E9
                           ICQ# 104246806
------------------------------------------------------------------------




> -----Original Message-----
> From: Dan Armak [mailto:danarmak@g.o]
> Sent: Wednesday, July 18, 2001 4:13 PM
> To: gentoo-dev@××××××××××.org
> Subject: [gentoo-dev] New system to replace USE flags
>
>
> Hi all,
>
> This is a followup to the discussion on the thread
> "Suggestion: DONT_USE
> flags". It describes a new (suggested) system to replace USE
> flags. I don't
> include the reasons for switching, they should be obvious.
>
> This is a very long post. It includes not just ideas but
> syntax examples etc.
> This are just examples, sometimes not even suggestions. If
> even half of what
> I've written here is implemented, it will be complete success
> for this memo.
>
> Comments are gladly accepted, only please try to read
> everything first.
>
> -------
>
> For clarity, let's call the new system With flags.
>
> With flags can serve different purposes:
> 1. They can set usage of shared libraries e.g. qt, sdl.
> 2. They can set ebuild-specific options and program-specific
> configuration
> details. This doesn't mean duplicating the program's
> configuration files, but
> rather more global things.
> 3. They can address h/w availability & utils (e.g. mmx,
> 3dnow, pcmcia) and
> other misc. things.
> This isn't an important distinction, the above 3 things are
> just examples.
>
> In make.globals (or somewhere else), a large number of With
> flags will be
> defined. They will all have default values (yes/no), either static or
> dynamically determined based on the values of other With flags.
>
> Note: I may be misunderstaing the use of make.globals. What I
> need is a file
> with unchanging factory settings, which can be customized in
> make.conf.
>
> An entry will look like this (2 lines):
>
> qt=yes
> an X interface library, used e.g. by KDE.
>
> Every With flag can have 2 parts of increasing verbosity:
> 1. Name. ex: qt. Default value appended.
> 2. Description. ex: an X interface library, used e.g. by KDE.
>
> The above gives an example of a static definition of a flag's
> default value.
> A dynamic definition would look like this:
>
> flagA=yes
> flagB=no
> flagC=flagA		# gives yes
> flagD=!flagA		# ! is not, gives no
> flagE=flagA|flagB	# | is inclusive or, gives yes
>
> and so on.
>
> In make.conf there will be a partial list of flags,
> preferrably with short
> comments, for user setting. A user can thus override any
> default setting. He
> can also add to make.conf any flag from make.globals and set
> it, even if it
> isn't in make.conf's default list.
>
> An example entry in make.conf:
>
> qt=yes # override here
> an X interface library, used e.g. by KDE. # This is a description
>
> The make.conf entry's description might be longer than the
> make.globals one.
>
> The default list should only include things which apply to
> more than just one
> or two packages, and which can be understood by the average end
> user/developer who isn't particularly familiar with the
> library/package
> discussed. No ebuild-specific (e.g. configuration) settings
> should go here.
>
> The default way of will be non-interactive, essentially the
> same as it is
> now. However, emerge (and ebuild) will accept a --interactive
> parameter.
>
> Whenever an ebuild needs to make any decision, it will call a
> function
> provided by emerge (or ebuild). So (I know this isn't a shell
> script, but I
> hate shell scripts!):
>
> # need to know whether to build qt interface
> result = with(qt, "foo uses qt to such and such an effect.")
>
> The second parameter to the with function is the description of the
> applicability of the With flag to this specific ebuild, and
> what the ebuild
> will do without it.
> The ebuild will get a response, it doesn't need to know how
> the decision was
> made.
>
> The function will have two modes: interactive and noninteractive.
>
> In noninteractive mode (the default), the With answer will be
> decided based
> on the default value (from make.globals) and the user-defined
> value if
> present (make.conf).
>
> In interactive mode, activated by the --interactive command
> line parameter,
> the user will be asked to decide. This is where the
> description of the flag
> is used.
> The user will see:
>
> # emerge --interactive foo.ebuild
> Calculating dependencies.. done!
> >>> emerge foo to /
> Decide: qt (default yes, override No):
> Description: an X interface library, used e.g. by KDE
> Specifics: foo uses qt to such and such an effect.
> [y/N]
>
> Note: not all flags need to be defined somewhere! If an
> ebuild calls with on
> an undefined flag, it needs to supply a default value. This
> is the value
> returned to it in noninteractive mode. The call would become:
>
> result = with(qt=yes, "foo uses qt to such and such an effect.")
>
> Dynamic definitions can be used as well as static, as defined earlier.
>
> The next thing to have is choice betwen mutually exclusive
> With flags (this
> is sorely lacking in the USE system).
>
> An ebuild might look so:
> # Choose between mutually exclusive sound output interfaces
> result=which(sdl_mixer, libmikmod, "Any one of these will do
> for sound.")
>
> In interactive mode, the user will see:
>
> # emerge --interactive foo.ebuild
> Calculating dependencies.. done!
> >>> emerge foo to /
> Choose: sdl_mixer, libmikmod (default sdl_mixer):
> Specifics: Any one of these will do for sound.
> [sdl_mixer/libmikmod]
>
> sdl_mixer is default, simply because it is named first. That
> is, the ebuild
> should pass the name of what it wants as default first.
> Of course this will accept more than two flags at a time.
> There is no Description (only Specifics) because this is not
> a 'generic'
> situation. An ebuild can request choice between any
> combination of flags in
> any order.
> The last parameter passed to Which is thus the Specifics
> string, all the
> others are taken to be names of With flags.
>
> In non-interactive mode, the which function will simply
> return the first flag
> named, sdl_mixer in this example.
>
> As above, a flag undefined in make.globals and make.conf can
> be used. No
> default value for it is needed. You can just pass a list of flags.
>
> -------
>
> Subsystem: default values of mutually exclusive choices - groups:
>
> It is true that an ebuild can pass any list of flags and get
> a result.
> However, for noninteractive operation, it would be very
> useful to assign
> default results outside the ebuild (i.e. not by selecting the
> order of flags
> passed to which).
> For this purpose, flags can be 'registered' in make.globals
> (or make.conf) as
> belonging to a group (or several groups). An example make.* entry:
>
> sdl_mixer=yes (audio-out)
> Description of sdl_mixer.
>
> libmikmod=yes (audio-out)
> Description of libmikmod.
>
> The entries thus classified will be arranged by group. The
> first flag in a
> group to be listed becomes the default choice for that group.
>
> A flag can be part of any number of groups, or none. Example:
> libggi=!libsdl (audio-out,video-out)
>
> Whenever an ebuild calls which on flags that are all part of
> one group (e.g.
> audio-out), this becomes the default for an interactive
> choice, and the
> result returned from a noninteractive one.
>
> The ebuild doesn't need to know the name of the group, or
> even that there is
> one.
>
> And, if even this isn't enough, we could add a Groups section
> in make.* which
> would:
> 1. Optionally define a group as a list of flags, even if
> those flags don't
> specify themselves as part of the group.
> 2. Define the group's order.
> 3. Provide an extra description of the group.
> For example:
>
> <groups>
> audio-out=libmikmod,sdl_mixer,libggi
> The audio-out group is foobar foobar foo.
>
> In this example, the order in whch the flags are defined is
> overriden, and
> libmikmod is set to be the new default choice.
>
> The reason we have an entire list and not just a default
> value is subgroups.
> If an ebuild asks
> result=which(sdl_mixer,mikmod,libggi,"select audio lib")
> then it will get libmikmod (from noninteractive mode) since
> it's first in the
> list defined in make.*'s <groups>.
> If however it says result=which(libggi,libmikmod,"subgroup
> choice") then it
> will get sdl_mixer because that's the best ('foremost')
> choice left without
> sdl_mixer.
>
> -------
>
> Comments welcome!
>
> --
>
> Dan Armak
> Gentoo Linux Developer
> Matan, Israel
>
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@××××××××××.org
> http://cvs.gentoo.org/mailman/listinfo/gentoo-dev
>