Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 19456

Summary: ufed enhancement
Product: Gentoo Linux Reporter: Fred Van Andel (RETIRED) <fava>
Component: Current packagesAssignee: Portage Tools Team <tools-portage>
Status: VERIFIED LATER    
Severity: enhancement CC: alpeterson, narada.sage, pez, truedfx
Priority: Low    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---

Description Fred Van Andel (RETIRED) gentoo-dev 2003-04-17 00:15:57 UTC
As per my discussion with yourself (robbat2) and seemant. 
 
It would be nice to have groups of use flags in ufed. 
So if you want kde support it automatically turns  
on "kde qt arts". If you don't want it, it turns off  
qt and arts. If you want multimedia then it turns  
on whatever flags are required etc.
Comment 1 Narada Sage 2003-04-17 22:03:58 UTC
Having thought about the idea of ufed I have a few things to say.

(1) Local and global use flag distinction

As there are far too many use flags local and global I propose the setting of two variables in make.conf, USE and USE_LOCAL for instance.  That way, they can be split up and become easier to view and manage by hand or ufed.  Local use flags are immensely useful and are growing in number fast and should be managed suitably.

(2) Environment variables vs. use flags

Here is the classic issue of whether an ebuild should use environment variables, use flags, a combination of both or one of them exclusively and consistently.  Personally, I feel that the use of environment variables should be minimised in support of local use flags.  Is there a policy on which of these should be used in what circumstance and to what extent?  Ufed can perhaps take this concept into account.

(3) Basic ufed operation

I seriously suggest that the fundamental operation of ufed 0.2 is reviewed and recreated as it seems to be behaving in the most odd and unexpected ways resulting in a great deal of inconvenience.  For example, flags that are not selected become active and flags that are active are neither in make.conf nor in default use flags.

(4) Use flag profiles

Ufed could support profiling of use flags.  This would have the following benefits.  One will be able to choose from client, server and laptop profiles just like with kernels.  Also, one will be able to create use flag scenarios for   non-local machines from the current machine.  For this, it must be able to write to files other than make.conf.  As already mentioned by Fred Van Andel on a similar note these profiles could either be by machine or by category but if you ask me category profiling seems quite conflicting and subjective.

(5) Descriptions of use flags

On all channels of communication, forums, emails and so on it has often been expressed that it is not immediately obvious what a use flag does and whether it should be enabled or disabled.  If a more information could be provided regarding the implication of each use flag than is already available it would be helpful.  This may even include a quick lookup of which packages use a certain use flag.  At the moment I use the following: find /usr/portage/ -name '*.ebuild' | xargs grep IUSE | grep <useflag> to find out which packages utilise a certain use flag.  If ufed can provide similar information it would be easier to find out how widely it is used and whether the packages are of any relevance to the user.

I would be curious to hear your thoughts on these topics and also on the progress of this whole issue.  I look forward to the next version.  Many thanks.
Comment 2 Fred Van Andel (RETIRED) gentoo-dev 2003-04-17 22:29:32 UTC
I am in the process of updating ufed now to address some of these issues: 
 
(1) Local and global use flag distinction 
(2) Environment variables vs. use flags 
(4) Use flag profiles 
These issues need to be addressed at a level above mine, my role is to update usfd 
and not to set policy. 
 
(3) Basic ufed operation 
The problem here is that there are 5 ways to set or unset a use flag and ufed only 
knows about 2 of them. Ufed understands make.globals and make.conf, ufed does 
not understand use.mask and use.defaults or the environment. 
 
When I am finished ufed will understand the firstl 4 meathods as well as say why 
something is set or unset. there is nothing I can do about setting flags via the 
environment, that is more of an emerge time activity. 
 
(5) Descriptions of use flags 
Code is being written now. 
 
Comment 3 Narada Sage 2003-04-26 12:39:25 UTC
Many thanks for having a look at my suggestions and providing feedback on them.  I'd like to add one more enhancement, number 6.

(6) Core use flags
Are there a core set of use flags that are critical to the successful functioning of a system or that are required by the base packages of a system?  If so, perhaps they should be excluded from modification.  Here's what I mean.  For example, how would a system behave if installed and managed with merely USE="-*" i.e. with no use flags whatsoever?  If doing this impairs any essential functionality in any significant way for the system or individual packages then these use flags, exclusion of which causes issues, should be included without offering a choice for safety.  There are many use flags included in make.defaults and I'm thinking that one of the reasons must be to safeguard those who neglect to set use flags manually in make.conf.  Consequently,  perhaps a core set of flags may exist.  If these were made separate then exclusion or inclusion of the remainder should not matter.  Just some food for thought.
Comment 4 David M. Andersen 2003-04-30 23:40:52 UTC
This was probably already mentioned, but there should be some sort of additional user-specific use flag descriptions file as changing the default one is "bad".  However, any flags not in /usr/portage/profiles/use.desc that are in the current use settings are removed by ufed when one saves.
Comment 5 Fred Van Andel (RETIRED) gentoo-dev 2003-05-01 00:29:50 UTC
Quote: 
   However, any flags not in /usr/portage/profiles/use.desc that are in the  
   current use settings are removed by ufed when one saves. 
 
I believe that was the default behavior of 0.2. The current version (0.31) is in testing  
and does not exhibit that behavior. 
 
ACCEPT_KEYWORDS="~x86" emerge ufed 
 
should get you the latest version 
Comment 6 CJ Kucera 2003-05-06 12:24:07 UTC
(This seems like a generic "ufed enhancement" bug so I'll add here instead of creating a new one)

Personally, I'd like to have ufed use a trinary state for packages, rather than the binary state currently in use.  Here's my idea:

  * Instead of just [X] and [ ], it would be possible to choose [X], [-], and [ ].
  * These values would correspond exactly with the values set in make.conf, as
    opposed to being "conglomerate" values of make.defaults, make.conf, etc...

This really isn't necessary for *most* cases, but there are a few corner examples I can think of where it might be useful.  For instance, I want to ensure that any optional CUPS support will always be built in, so I defined "cups" in my make.conf.  This is currently unnecessary, as "cups" is already defined in make.defaults, but make.defaults could change with a newer version of Portage without my knowing it, and because I haven't specified it in make.conf, I may lose some optional CUPS support.

Conversely, I had previously specified "-maildir" in my make.conf, because I didn't want any maildir support.  This is also currently unnecessary, because "maildir" doesn't appear in make.defaults or use.defaults, but if it ever got added to either of those files, I'd suddenly be compiling with maildir support.  The value in my make.conf is a safeguard.

Again, these are obviously kind of corner cases, so it's probably not worth retooling ufed to handle it, but personally I'd find that system more to my liking.

Thanks for listening,
CJ
Comment 7 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2003-05-06 12:39:53 UTC
CJ: Ultimately we will support this, but it's not possible given the current dialog-based interface without a LOT of work.

Comment 8 Fred Van Andel (RETIRED) gentoo-dev 2003-05-06 13:09:26 UTC
<Quote>
   Personally, I'd like to have ufed use a trinary state for packages,
   rather than the binary state currently in use.  
</Quote>

The dialog library that ufed uses does not support tri-state flags. The kernels make menuconfig code accomplished this via a hacked version of dialog and I really don't want to go that route.

<Quote>
   I can think of where it might be useful.  For instance, I want to 
   ensure that any optional CUPS support will always be built in, so
   I defined "cups" in my make.conf. This is currently unnecessary, 
   as "cups" is already defined in make.defaults, but make.defaults 
   could change with a newer version of Portage without my knowing 
   it, and because I haven't specified it in make.conf, I may lose 
   some optional CUPS support.
</Quote>

One way of dealing with this would be to include -* at the beginning of your use flags, this disables the processing of make.defaults, this will allow you to specify more compleatly which flags are included.  There is currently no way to bypass the processing of use.defaults, that is planned for a future version (via the USE_ORDER variable. See man make.conf for info)

We are limited with what we can do because we can only implement features that portage supports. 
Comment 9 CJ Kucera 2003-05-06 14:20:17 UTC
<Quote>
  The dialog library that ufed uses does not support tri-state flags. The kernels make
  menuconfig code accomplished this via a hacked version of dialog and I really don't
  want to go that route.
</Quote>

Ah, I wasn't aware of that.  Yeah, hacking up dialog would be pretty messy, I certainly wouldn't want to do that, either.

<Quote>
  We are limited with what we can do because we can only implement features that portage
  supports. 
</Quote>

Yeah, totally.  The dialog limitation is probably the biggest impediment to doing what I suggested, and it's a pretty big one to get around.  Also, like I said, my scenarios probably don't affect more than a handful of oddballs like me, so I'll just do without.  It's a good tool regardless.  :)
Comment 10 Narada Sage 2003-05-06 14:43:07 UTC
Hello.  Excellent work on ufed 0.32 and thank you for participating in feedback to enhancement suggestions.  It's great to finally have a reliable method of managing use flags.  Having tried ufed 0.32 there's one thing that's bothering me.  The way local and global use flags are scattered amongst each other is unsettling.  It would be easier on the eyes to have two separate panes/sections one after another.  How does that sound?  Many thanks.
Comment 11 Fred Van Andel (RETIRED) gentoo-dev 2003-05-06 16:44:49 UTC
It is my intent to seperate local and global use flags, especially since there is the potential for a LOT of local flags.  Unfortunatly the dialog interface used is fairly limiting and my goal was to fix/update the current version before embarking on a major interface change.

The next major revision (0.40) will use a ncurses interface and will be much more flexible.
Comment 12 Narada Sage 2003-05-09 07:49:42 UTC
Hello.  Here I have an enhancement idea and a question.

Enhancement: This is a wild thought and I'll leave it up to you to decide its merit.  Given the rapid proliferation of local use flags and packages which use them and also an increase in how many flags each package uses a more convenient method of selecting local use flags 'package-wise' is called for.  At the moment, I do emerge -vp <packagename> and then go into ufed and alter flags.  However, this has the drawbacks that there are what seem like hundreds of local and global flags to sort through just to make modifications to flags for one package.  So my suggestion is that perhaps ufed should begin taking arguments so that ufed <packagename> will bring up the console interface with only the use flags for that particular package and allow selection and deselection and saving into make.conf.  This is quick and easy and can be useful for packages such as gentoo-sources and xfree which have a lot of flags.  Ufed without any arguments will bring up all flags.  I'm not sure how crazy this idea is but I'd be interested to hear your view on it.

Question: Out of curiosity, why was ufed designed with dialog which is now considered to be fairly limited?  Is it because an immediate working release was required and that implementing an ncurses interface would take much longer?  If so, what would you say is the timeframe for release 0.40?  Many thanks.
Comment 13 Fred Van Andel (RETIRED) gentoo-dev 2003-05-09 11:35:06 UTC
<quote>
So my suggestion is that perhaps ufed should begin taking arguments so 
that ufed <packagename> will bring up the console interface with only 
the use flags for that particular package and allow selection and deselection and saving into make.conf.  This is quick and easy and can be useful
for packages such as gentoo-sources and xfree which have a lot of flags.
</quote>

At some time I fully expect that portage will implement per package use flags which would be a much better solution to your problem.  However this would require changes to portage, and the portage developers are currently busy implementing security featured. I do not know when they will get around to the less critical enhansements to portage.  When per package use flags are implemented ufed will be revised to accomodate them.

<quote>
Question: Out of curiosity, why was ufed designed with dialog which is now onsidered to be fairly limited?  Is it because an immediate working release was required and that implementing an ncurses interface would take much longer?  If so, what would you say is the timeframe for release 0.40?  Many thanks.
</quote>

I cant speak for the original developer but I expect that at the time dialog was the appropriate tool for the expected role of ufed. Over time the role of ufed has changed and been enhanced and so we need to revise the tools that we use to accomidate these new requirements.

There is no schedule for 0.4
Comment 14 Narada Sage 2003-05-20 17:54:38 UTC
fava wrote:
---
At some time I fully expect that portage will implement per package use flags which
would be a much better solution to your problem.  However this would require changes
to portage, and the portage developers are currently busy implementing security featured.
I do not know when they will get around to the less critical enhansements to portage.
 When per package use flags are implemented ufed will be revised to accomodate them.
---

There seems be a misunderstanding.  Portage **already** has per package (i.e. local) use flags.  An example can be seen by doing 'emerge -vp gentoo-sources' which will list all local flags required for that package.  So I'm a complete loss as why you say they are yet to be implemented.  My suggestion is based on the fact that when you wish to emerge a package that has many use flags like php (or xfree) then you may simply type 'ufed php' and that will bring up the UI with only those flags allowing you to review them quickly if need be.  I understand however if this suggestion is turned down due to further complicating the utility.
Comment 15 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2003-08-06 13:15:39 UTC
Fava has been doing the work on this last I checked.
Comment 16 Aaron Peterson 2004-04-01 03:13:04 UTC
ARRGG!

ufed rearranged all of my useflags in my make.conf!

I had them ordered by date of inclusion!!!
Now I don't know what flags I care about and what ones I don't care about!

I typically have a couple that I'm playing with, and may want to disable soon.. and sometimes I forget that I added them, and go back when they have broken something...

Well.. now I can't!


I think it's a good thing to have groups of use flags... 

May I recommend that ufed has a ufed section for it's useflags so it doesn't mess up mine?

USE=$USE+"blahblabhalbkjblajks"
?


USE="X aalib acpi acpi4linux alsa amd apache2 apm arts artswrappersuid avi berkdb bonobo cdr cjk cjkcrypt crypt cscope cups dga directfb doc dv dvb dvd encode esd evms2 faad fbcon ffmpeg flac flash foomaticdb freetype fs gdbm ggi gif gnome gpm gstreamer gtk gtk2 gtkhtml guile imagemagick imap imlib jack java javascript joystick jpeg kde kerberos krb4 ldap libcss libdvdread libg++ libwww mad maildir md5sum mdb mikmod mmx motif mozilla mpeg mpeg4 mule mysql nas ncurses net nls nptl nvidia oggvorbis opengl oss pam pdflib perl pic png postgres python qt quicktime readline samba sasl scanner sdl slang spell sse ssl svga tcltk tcpd tetex tiff transcode truetype unicode usb v4l vhosts virus-scan x86 xine xinerama xml2 xmms xv xvid zeo zlib"


Comment 17 Seemant Kulleen (RETIRED) gentoo-dev 2004-05-29 18:21:21 UTC
Fred, where are you??
Comment 18 Marius Mauch (RETIRED) gentoo-dev 2004-12-08 20:47:19 UTC
GLEP 29, although ufed will probably be dead when it gets implemented in portage.
Comment 19 Paul Varner (RETIRED) gentoo-dev 2010-04-08 16:44:57 UTC
Harald, can you look at this and see if it should be reopened or closed?
Comment 20 Harald van Dijk (RETIRED) gentoo-dev 2010-04-09 23:05:49 UTC
(In reply to comment #19)
> Harald, can you look at this and see if it should be reopened or closed?

I think this can be closed. There are a few things in here that would be good to add, but there have been more recent, still open bugs for those already (and they're not easily done).