Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 205359 - app-portage/ufed could support more USE-style-variables
Summary: app-portage/ufed could support more USE-style-variables
Status: CONFIRMED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Tools (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: Sven Eden
URL:
Whiteboard:
Keywords:
: 360075 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-01-11 19:36 UTC by Matthias Vill
Modified: 2020-12-16 07:19 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 Matthias Vill 2008-01-11 19:36:32 UTC
It would be nice if ufed would support the variables described in the $PORTDIR/profiles/profiles/desc/ dir.
They all seem to follow the use-syntax and take up some of the functionality USE used to handel.

Nice work and thanks in advance.
Comment 1 Harald van Dijk (RETIRED) gentoo-dev 2008-01-11 20:13:07 UTC
They actually don't work like USE flags: try, from a clear make.conf, what effect USE="" has, and then try what effect VIDEO_CARDS="" has: the former does not disable the profile USE flags, but the latter does disable the profile VIDEO_CARDS. Additionally, for LINGUAS, for certain packages the order matters: compare the default language of firefox built with LINGUAS="fr en" to that with LINGUAS="en fr".

Editing of USE_EXPAND variables would be a nice addition to ufed, but getting that right is not as easy as it seems.
Comment 2 Matthias Vill 2008-01-12 00:41:36 UTC
I admit I just looked briefly over the files. The Description files and the function are quite similar, so I thought they would be equally coded to reduce the overhead.
But you're right, as there is no such "default language" inside make.conf and since you don't need generic drivers if you are sure to know which graphics you have it makes sens to handle it differently.

As you said it would be quite nice to be able to edit them and emerging apache today just brought me to the questions how long plain use-flags will be used for bigger packages.
I know there where quite a lot USE-flags and so this seems to be useful, but it also complicates the configuration of such packages.

Great would be to support these flags along with a package filter. Even grater would be a plugin to emerge where you can adjust the interesting flags in -a -mode, but I guess, that's far future.

I like you're work and I am sure you can make it. If I can help you in some matters I will try, but I guess I can't, cause I neither know portage as good as you nor can I code Perl in a structured and fast manner.
Comment 3 Harald van Dijk (RETIRED) gentoo-dev 2008-01-12 16:02:59 UTC
(In reply to comment #2)
> I admit I just looked briefly over the files. The Description files and the
> function are quite similar, so I thought they would be equally coded to reduce
> the overhead.

For figuring out which flags to display, you're right, that is possible without too much effort. It's only the slightly different behaviour by portage that's a problem.

> But you're right, as there is no such "default language" inside make.conf and
> since you don't need generic drivers if you are sure to know which graphics you
> have it makes sens to handle it differently.

I don't understand entirely what you mean here. You can set LINGUAS in make.conf, and it would be possible and make sense for ufed to support adding and (re)moving entries in the LINGUAS variable there using linguas.desc, it's just that a lot of the logic would need to be updated or rewritten.

> Great would be to support these flags along with a package filter. Even grater
> would be a plugin to emerge where you can adjust the interesting flags in -a
> -mode, but I guess, that's far future.

Indeed.

I'm afraid I haven't been able to spend a lot of time working on ufed recently, and while I hope I can change that, I don't think that is going to happen soon, sorry...
Comment 4 Sven Eden 2012-12-30 11:19:26 UTC
I could add some sort of "mode" for ufed to handle, toggled by a key stroke. This could be USE (default), APACHE2_MPMS, APACHE2_MODULES, CAMERAS, LIBREOFFICE_EXTENSIONS, GRUB_PLATFORMS, INPUT_DEVICES, VIDEO_CARDS, LINGUAS, ENLIGHTENMENT_MODULES and maybe others.

There are just these two problems:

A) It makes no sense to show GRUB_PLATFORMS if grub2 isn't installed.
  But it is a good preparation to show and manage GRUB_PLATFORMS *before* grub2 is emerged.
So. How to separate these cases? Is it necessary to separate these cases? I do not think it is possible for ufed to find out what is a sensible list of alternate variables.
Therefore my current idea is to solve the second problem and filter out nothing.

B) Which of those alternate variables actually do exist and are relevant to the machine? It would be a nightmare to go and have them hard coded. I'll first need to figure out how to teach ufed to go and find this stuff out for itself. Otherwise I'll see myself confronted with bugs like "Variable FOO is missing..." ;)
Comment 5 Sven Eden 2013-01-07 11:48:30 UTC
*** Bug 360075 has been marked as a duplicate of this bug. ***
Comment 6 Roman Žilka 2013-01-22 14:34:48 UTC
IMHO it would be a great step forward if ufed could do nothing more but simply offer a full selection of flags for every (I mean each and every) variable and leave it up to the user to turn the flags on/off in a meaningful way. In this form it would have to be with a big "you know what you're doing" exclamation mark, of course, but I bet lots of people would readily welcome such a feature.
Comment 7 Sven Eden 2013-01-22 15:41:24 UTC
(In reply to comment #6)
> IMHO it would be a great step forward if ufed could do nothing more but
> simply offer a full selection of flags for every (I mean each and every)
> variable and leave it up to the user to turn the flags on/off in a
> meaningful way. In this form it would have to be with a big "you know what
> you're doing" exclamation mark, of course, but I bet lots of people would
> readily welcome such a feature.

The problem remains on how to find out which flags do exist. I will leave this bug alone until after the next release. But as "equery u" *can* show these flags, I guess I'll simply go spying how they do it. At least I know that those are not found in /usr/portage/profile/use.* ;)
Comment 8 Roman Žilka 2013-01-23 11:51:06 UTC
Maybe emerge --info lists all these variables. It sort of appears so.