Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 268891 - Add support for USE flags with portage @sets
Summary: Add support for USE flags with portage @sets
Status: CONFIRMED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Enhancement/Feature Requests (show other bugs)
Hardware: All All
: High enhancement (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on: 272488
Blocks: 144480
  Show dependency tree
 
Reported: 2009-05-07 01:31 UTC by Ronan Arraes Jardim Chagas
Modified: 2011-03-23 00:55 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ronan Arraes Jardim Chagas 2009-05-07 01:31:37 UTC
Is there a way to add to portage the possibility to configure a specific USE flag for a set of applications?

Today I have the problem: I want to enable doc USE flag for all KDE applications, but just KDE applications to avoid a huge files download for packages that I just don't want it. The only option that I found was add package by package (or create a script, or something) to packages.use.

I think that should be a mechanism to add a USE flag for a set. For example, in my case, it will be very useful if packages.use supports something like:

@kde-4.2 doc

So every package in the set @kde-4.2 that has doc USE flag will be compiled with it, and the packages that don't have it won't be changed.

Reproducible: Always
Comment 1 Markos Chandras (RETIRED) gentoo-dev 2009-05-07 08:27:51 UTC
Take a look on qting-edge overlay sets. Portage already support this operation
Comment 2 Ronan Arraes Jardim Chagas 2009-05-07 12:09:46 UTC
I saw the set files on qting-edge overlay but I didn't see anything like what I am proposing here. Could you show me please? 
Comment 3 Jonas Bernoulli 2009-05-22 20:50:38 UTC
(In reply to comment #1)
> Take a look on qting-edge overlay sets. Portage already support this operation
> 

That's not what Ronan asked for. He wants to be able to set useflags for all packages belonging to a set in the same file he would do so for a single package too: portage.use. In the mentioned overlay a useflag is set for all packages belonging to that a set in the file where the set is defined by adding the useflag to each of the packages individually.

For the purpose this fullfills in the overlay this is very useful. (Essentially there are to sets containing the same packages but with different useflags.) However doing something like "set the flac useflag for all packages that are media players" also is a reasonable usecase. If you want that setting "@media-players flac in portage.use is what you would want.

At least I am interested in that feature too.
Comment 4 Sebastian Luther (few) 2009-06-10 09:47:20 UTC
GLEP 21 [1] talks about use flags in package.use for sets and why it is not a good idea. The first two reasons can be circumvented by a simple rule, like: "if an entry for a package exists in package.use, it takes precedence over what ever a set wants to set (similar for subsets). I don't understand the third argument. I can think of another problem. What happens if a package belongs to two sets and the sets have different use flags set? Or what if a subset of some set wants something else than another set. There is a clear rule needed to decide which setting takes precedence.

What about this:
final_list = [], current_list = [], temporary_list=[]
1) Read atoms and sets from package.use into current_list.
2) For atom in current_list:
     if the atom is already in final_list
        -add the new use-flags to it. If a new useflag contradicts with an old useflag, ignore the new useflag.
        -remove atom from current_list

      elif the atom is not in the final list
             -If an atom has invalid use_flags (contains +use1 and -use1) 
                 either A) error out and ignore both or B) choose what comes first
             -Move atom from current_list to final_list.
3) Expand all sets in current_list to atoms and subsets into temporary_list;
4) current_list=temporary_list
5) if len(current_list)>0 goto 2
6) return final_list

Please tell me if I missed something and what you like better, A or B in step 2.
(I hope bugzi didn't screw the layout up too much)
And please explain what the third argument in GLEP 21 means.

[1] http://www.gentoo.org/proj/en/glep/glep-0021.html
Comment 5 Ronan Arraes Jardim Chagas 2009-06-10 13:47:52 UTC
I think it is a very interesting option, to make an entry for particular package in packages.use has a higher priority than the option specified for sets.

If you think it would mess up too much, maybe it will be more interesting for programming reasons to create another place to put sets use options, like /etc/portage/sets.use

In my opinion, if it was found conflicting sets option, like, a packages belongs two sets and one is setting -use1 an another +use1, than it has to show a message indicating the conflict but use the last (or first :D) option found in packages.use or sets.use.
Comment 6 Maciej Mrozowski gentoo-dev 2009-08-20 20:12:28 UTC
Please take a look at bug 272488.
Comment 7 Nao Nakashima 2010-03-24 06:47:49 UTC
About conflicting USE flags on sets:
I think portage can follow same rules for packages use-flags.

E.g. package.use contain that:
category/package use1 -use2 use3
category/package -use1 use2

And result will be:
category/package -use1 use2 use3

Same rules for the sets.

About conflicting use flags on sets and packages:
There can be new "sets" layer in USE_ORDER variable.