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.
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.
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.
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.
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.
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
(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
CJ: Ultimately we will support this, but it's not possible given the current dialog-based interface without a LOT of work.
<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.
<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. :)
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.
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.
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.
<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
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.
Fava has been doing the work on this last I checked.
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"
Fred, where are you??
GLEP 29, although ufed will probably be dead when it gets implemented in portage.
Harald, can you look at this and see if it should be reopened or closed?
(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).
