Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 10013 - Request: USE Flags handle '+flag'
Summary: Request: USE Flags handle '+flag'
Status: RESOLVED WONTFIX
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Unclassified (show other bugs)
Hardware: x86 All
: High normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
: 119484 (view as bug list)
Depends on:
Blocks:
 
Reported: 2002-10-31 09:22 UTC by Dana Powers
Modified: 2011-10-30 22:18 UTC (History)
2 users (show)

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


Attachments
Adds an option for displaying a plus ('+') symbol before activated USE flags to `emerge` (Add_plus_symbol_display_option.patch,3.21 KB, patch)
2006-01-31 02:56 UTC, email_deleted_GqKU
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dana Powers 2002-10-31 09:22:57 UTC
It would be nice if USE Flags would handle both the regular syntax, which is
'-flag', and 'flag' for removing and adding a given USE Flag, as well as 
recognizing '+flag' as a synonym for just 'flag'. Currently, if you 
accidentally put your USE flags as all '+flag' instead of just 'flag' (speaking 
from painful experience), portage will ignore them and resort to the defaults. 
Having this happen to youis very annoying. I misread the instructions, and it 
is certainly my fault, but hey, I figured I'd file a bug report because the 
chances that this is a common mistake may be fairly high, and Im guessing the 
work to create code to support it would be fairly low. Happy [en]trails.
Comment 1 Nicholas Jones (RETIRED) gentoo-dev 2002-10-31 11:58:14 UTC
USE="-* flag"

Having + would probably confuse more people. They'd either expect it
to append, or they'd get confused about the function of more than one
+flag.
Comment 2 solar (RETIRED) gentoo-dev 2006-01-18 14:24:00 UTC
*** Bug 119484 has been marked as a duplicate of this bug. ***
Comment 3 email_deleted_GqKU 2006-01-18 15:36:31 UTC
From #119484 comment 2 (In reply to comment 1)
> comment #2 on bug #10013 still applies.
>


Comment #2 on bug #10013 never applied.


From #119484 comment 2 (In reply to comment 1)
> Adding a + is redundant
>


It is not redundant. The *lack* of a plus symbol is a synonym for the presence of a plus symbol. It is an error not to permit (and not use by default), a plus symbol, before activated USE flags, as it is the complete way of indicating activation. If the simple presence of the USE flag meant it was activated, then deactivated USE flags should not be shown at all, which is not what we want.

Besides, even if it was redundant, it would still be good, as it adds readability, and is a most common standard (as said in https://bugs.gentoo.org/show_bug.cgi?id=119484, in mathematics). Moreover, it is short to write.


(In reply to comment #1)
> USE="-* flag"
> 
> Having + would probably confuse more people.
>


It won't confuse anyone. Why would it? The meaning of your example would be enhanced if we could use a plus symbol (which, as said, already is the case, if not for the warning notices -well, maybe it wasn't, back in 2002). We first deactivated all the USE flags, then we reactivate some USE flags... the '+' symbol, here, would be used in his most standard and well known meaning: adding something. The simple presence of the USE flag does not mean anything, if we don't assume it is a synonym for a preceding '+' symbol.


Ok, maybe I shouldn't have opened a new bug report, after all. Please reopen this one, as it is not fixed at all and should be discussed and correctly resolved. (I guess the assignee should be also changed to "dev-portage@gentoo.org" -I added it to the CC list, for now-, and component and severity should be changed to "enhancement"...).
Comment 4 email_deleted_GqKU 2006-01-23 13:16:54 UTC
I just saw there were plusses before activated USE flags, for some times, before? (sys-apps/portage-2.0.54)

How come it has been removed?!

This bug report must be re-opened, this is a grave usability regression.
Comment 5 email_deleted_GqKU 2006-01-23 23:40:41 UTC
>
> From Jason Stubbs (http://forums.gentoo.org/viewtopic-p-3055244.html#3055244):
>
> [...] they were removed to save screen space
>


Saving space (and so little...) at the expense of usability is an error, and not a small one.


>
> From Jason Stubbs (http://forums.gentoo.org/viewtopic-p-3055244.html#3055244):
>
> [...] and to bring the display in line with how it would be set in make.conf.
>


The solution is to allow to use '+' symbols to activate USE flags in make.conf and package.use.
Comment 6 Jason Stubbs (RETIRED) gentoo-dev 2006-01-23 23:50:06 UTC
<required reopen comment />
Comment 7 Jason Stubbs (RETIRED) gentoo-dev 2006-01-24 00:10:58 UTC
(In reply to comment #3)
> From #119484 comment 2 (In reply to comment 1)
> > Adding a + is redundant
> 
> It is not redundant. The *lack* of a plus symbol is a synonym for the 
> presence of a plus symbol. It is an error not to permit (and not use by 
> default), a plus symbol, before activated USE flags, as it is the complete 
> way of indicating activation.

Having a plus symbol is not and never was a synonym for activation nor is it and never was the complete way of indicating activation. Listing the flag on its own however is and always was both of those things.

> If the simple presence of the USE flag meant it was activated, then 
> deactivated USE flags should not be shown at all, which is not what we want.

The clauses of your "if ... then ..." have no logical relation.

> Besides, even if it was redundant, it would still be good, as it adds
> readability, and is a most common standard (as said in
> https://bugs.gentoo.org/show_bug.cgi?id=119484, in mathematics).

So where do (-masked_flag), new_flag% or changed_flag* fit into this?

> Moreover, it is short to write.

How is adding characters shorter to write?

> (In reply to comment #1)
> > USE="-* flag"
> > 
> > Having + would probably confuse more people.
> 
> It won't confuse anyone. Why would it? The meaning of your example would be
> enhanced if we could use a plus symbol.

So what does +* mean? Enable everything? It's not currently possible.

> (which, as said, already is the case, if not for the warning notices -well, 
> maybe it wasn't, back in 2002).

The addition of the warning notices would have been what warranted this bug being marked FIXED.

> Ok, maybe I shouldn't have opened a new bug report, after all. Please reopen
> this one, as it is not fixed at all and should be discussed and correctly
> resolved.

"Correctly resolved". You seem to have a habit of assuming that you are always correct; that is not discussion.

(In reply to comment #4)
> This bug report must be re-opened, this is a grave usability regression.

"Grave"? You've got to be kidding me. "Regression"? If it was never what you deem to be fixed, how can you call it a regression?

(In reply to comment #5)
> > From Jason Stubbs (http://forums.gentoo.org/viewtopic-p-3055244.html#3055244):
> >
> > [...] they were removed to save screen space
> 
> Saving space (and so little...) at the expense of usability is an error, and
> not a small one.

You haven't said anything about how it's at the expense of usability other than citing mathematics without giving any references.

> > From Jason Stubbs (http://forums.gentoo.org/viewtopic-p-3055244.html#3055244):
> >
> > [...] and to bring the display in line with how it would be set in
> > make.conf.
> 
> The solution is to allow to use '+' symbols to activate USE flags in 
> make.conf and package.use.

And how about ACCEPT_KEYWORDS? FEATURES? package.{use,keywords}? Each of the files allowable in the profiles? Should all of these (and other) settings have each individual item prefixed with a plus symbol?

To go beyond all of the above, you're also assuming that the flags will only ever have binary state. This will not necessarily be the case.
Comment 8 email_deleted_GqKU 2006-01-24 02:52:23 UTC
(In reply to comment #7)
> (In reply to comment #3)
> > From #119484 comment 2 (In reply to comment 1)
> > > Adding a + is redundant
> > 
> > It is not redundant. The *lack* of a plus symbol is a synonym for the 
> > presence of a plus symbol. It is an error not to permit (and not use by 
> > default), a plus symbol, before activated USE flags, as it is the complete 
> > way of indicating activation.
> 
> Having a plus symbol is not and never was a synonym for activation nor is it
> and never was the complete way of indicating activation. Listing the flag on
> its own however is and always was both of those things.
> 


I was not talking about the way Gentoo saw this in the past, I was talking about the way the world saw this, meaning: the users.

>
> > If the simple presence of the USE flag meant it was activated, then 
> > deactivated USE flags should not be shown at all, which is not what we want.
> 
> The clauses of your "if ... then ..." have no logical relation.
> 


No logical relation? If presence means activation, then deactivation must be reflected by absence, not by a '-' symbol. How is that not logic?

What we want is a '+' symbol for activation, and a '-' for deactivation... the lack of symbol would be a synonym of the '+' symbol, as it is widely understood.


>
> > Besides, even if it was redundant, it would still be good, as it adds
> > readability, and is a most common standard (as said in
> > https://bugs.gentoo.org/show_bug.cgi?id=119484, in mathematics).
> 
> So where do (-masked_flag), new_flag% or changed_flag* fit into this?
> 


Just let them like they are, why would we care? There is no well known way of indicating new/changed states, so we created one... nothing more...


>
> > Moreover, it is short to write.
> 
> How is adding characters shorter to write?
> 


I said "short", not "shorter".

Moreover, if you care that much about space, just create an option for not printing '+' symbols for activated USE flags (which is, as the USE flag sorting problem, what should have been done to begin with -I'm pretty sure it would have taken you less time than discussing the issue here, and I, and others, wouldn't have had to discuss it either). Do no just remove them, because you, and some other people, might like it.

I'm not against new ways. I think it is a good thing to test experimental changes, when labeled as such in the documentation. Some will be good, some bad. The good ways (determined after at least months of use, by a lot of people), should be added as normal options in the documentation, and might, one day, be set as the default way of doing things (keeping the old way, at least for some time, as an option), the bad ways probably should removed (or kept, if some people really want them, and if it is cleanly implemented -might be removed from the documentation, however, if we one day want to remove it). Just don't go pushing your changes on the user, when they are obvious usability regressions for most. Yeah, some people will like it, and it may even really be good for them, but we all are different, and we should care about what is better for most (and avoid things that are bad for even some people, but it's not always possible, and not just timewise).


> > (In reply to comment #1)
> > > USE="-* flag"
> > > 
> > > Having + would probably confuse more people.
> > 
> > It won't confuse anyone. Why would it? The meaning of your example would be
> > enhanced if we could use a plus symbol.
> 
> So what does +* mean? Enable everything? It's not currently possible.
> 


Is "*" possible? No.

This USE="+*" seems pretty useful for testing purposes (as the USE="-*" already is)... it should be added.

You can't use the lack of functionnality as an excuse to remove or not add other good functionnalities... if you do that, we will never improve: we will regress, which is what is happening.


> > (which, as said, already is the case, if not for the warning notices -well, 
> > maybe it wasn't, back in 2002).
> 
> The addition of the warning notices would have been what warranted this bug
> being marked FIXED.
> 


A temporary fix, until it is properly supported. This is the only way of thinking right.


> > Ok, maybe I shouldn't have opened a new bug report, after all. Please reopen
> > this one, as it is not fixed at all and should be discussed and correctly
> > resolved.
> 
> "Correctly resolved". You seem to have a habit of assuming that you are always
> correct; that is not discussion.
>


Well, be sure I feel it is the exact contrary.

Things have been changed without even keeping options for well known good behaviours. People report about it, you go as far as opening a poll about it... (a poll which only shows half the voters didn't test the new way for a long enough time, if at all, and assume, for obscure reason, it feels better...). Ok, off topic.


> (In reply to comment #4)
> > This bug report must be re-opened, this is a grave usability regression.
> 
> "Grave"? You've got to be kidding me. "Regression"? If it was never what you
> deem to be fixed, how can you call it a regression?
>


The `emerge -pv` display change (the removing of the '+' symbol before activated USE flags), is a regression. There is no other way of calling it.

The lack of support for the '+' symbol before activated USE flags in make.conf and package.use, and the multiple identical warnings about it, when we try to use '+' symbols in these files (or on the command line), is a problem which should be resolved (and should have long ago, but I don't care about the past, and it's not me who is programming Portage), instead of using it as an excuse to remove the '+' symbol from the `emerge -pv` display...


> (In reply to comment #5)
> > > From Jason Stubbs (http://forums.gentoo.org/viewtopic-p-3055244.html#3055244):
> > >
> > > [...] they were removed to save screen space
> > 
> > Saving space (and so little...) at the expense of usability is an error, and
> > not a small one.
> 
> You haven't said anything about how it's at the expense of usability other
> than citing mathematics without giving any references.
> 


You said in yourself in https://bugs.gentoo.org/show_bug.cgi?id=117329#c1 that spotting an activated USE flag was hard.

The '+' symbol before activated USE flags enhance this.

I can understand features are not added, because devs have no time for this... (they do it on their free time, as I am, here, using my free time) but don't go removing good features, because you can't add others...

If you lack the time or motivation to allow '+' symbols in make.conf, package.use, etc. or don't know what to do about the implications of this changes, just go to the forum and ask the community for advice and time.


> > > From Jason Stubbs (http://forums.gentoo.org/viewtopic-p-3055244.html#3055244):
> > >
> > > [...] and to bring the display in line with how it would be set in
> > > make.conf.
> > 
> > The solution is to allow to use '+' symbols to activate USE flags in 
> > make.conf and package.use.
> 
> And how about ACCEPT_KEYWORDS? FEATURES? package.{use,keywords}? Each of the
> files allowable in the profiles? Should all of these (and other) settings have
> each individual item prefixed with a plus symbol?
> 


Just allow things like "+x86", "+sandbox", etc., and let the lack of symbol be a synonym of the '+' symbol, as it is the standard way of thinking around the world. "5" = "+5". No compatibility problems, except for people using an old version of portage, seeing '+' symbols and trying to use them... (when was the warning about '+' symbols added? If it in the current stable portage, then we should not care about older versions... these users will be warned they should not use '+' symbols, and the next time they'll update their portage version, they'll be able to use them... just a normal enhancement...)

As there will probably be some people wrinting things like "~+x86", print a fatal error, to inform the user the '+' should be before any other character.

Things like ACCEPT_KEYWORDS="+-amd64" mean we accept the activated deactivated amd64 keyword, which means we accept the "+amd64" keyword (possibily just written "amd64", as it is now). It is correct, as is "-+amd64", but a warning should be printed, as using multiple signs doesn't serve any purpose (we might as well print a fatal error anytime there is more than one sign used).

"ACCEPT_KEYWORDS" does not act as variables like USE or FEATURES. It already means accepting keywords, so ACCEPT_KEYWORD="+x86" does not mean "activating the x86 keyword", it means "accepting the activated x86 keyword" (more precisely, accepting the "+x86" keyword, and maybe there are ways to simplify this, but it is not the subject of this bug report). The "do not accept this keyword" is only possible by removing it from the list (which is, as said in a comment above, how the USE variable should act, if we refuse the use of the '+' symbol), except if we accept the "-+x86" writing, which is probably not what we want, even if it is correct (is there even a use to this? maybe people defaulting to ~x86, but wanting some stable packages, without Portage trying to update packages to the last ~x86 versions... might be worth discussing in another bug report, if not already done...).

I guess I'm not that clear, but anyway, FEATURES, ACCEPT_KEYWORD, etc. are not a problem. We should be able to use a '+' symbol with these too.

It's not even needed to ask about adding '+' symbols in default configuration files, profiles, etc., as the lack of symbol will be synonym of the presence of the '+' symbol. Of course, in the future, it might be good to officially always use '+' symbols, when activating USE flags, features, etc., but there is no need to push it.


> To go beyond all of the above, you're also assuming that the flags will only
> ever have binary state. This will not necessarily be the case.
> 


Adding options to USE flags, features, etc.? That's a whole different matter. If you ever use '+' symbols for other things than activating things, that'll be another major usability error. '+' and '-' symbols goes together. OF there is a '+' symbol, we MUST be able to use '+' symbols.


Sorry about the length, but, again, I would not have to write all this, if you just added non-default options...


Is there no usability team on Gentoo? If not, I think we should create one, for discussing this kind of problems.
Comment 9 Jason Stubbs (RETIRED) gentoo-dev 2006-01-24 03:43:42 UTC
(In reply to comment #8)
> (In reply to comment #7)
> > (In reply to comment #3)
> > > From #119484 comment 2 (In reply to comment 1)
> > > > Adding a + is redundant
> > > 
> > > It is not redundant. The *lack* of a plus symbol is a synonym for the 
> > > presence of a plus symbol. It is an error not to permit (and not use by 
> > > default), a plus symbol, before activated USE flags, as it is the complete 
> > > way of indicating activation.
> > 
> > Having a plus symbol is not and never was a synonym for activation nor is it
> > and never was the complete way of indicating activation. Listing the flag on
> > its own however is and always was both of those things.
> > 
> 
> 
> I was not talking about the way Gentoo saw this in the past, I was talking
> about the way the world saw this, meaning: the users.

This is wasting time. "The way the world saw this"? Further down, you've labelled half the voting users as ignorant because they don't agree with you on the point of use flag ordering. That doesn't really give much weight to what you see as "the world". If you feel strongly about this, start a new topic in the forums and show that there are a substantial number of people that care about this.
Comment 10 email_deleted_GqKU 2006-01-24 05:46:21 UTC
(In reply to comment #9)
> This is wasting time.
>


Yeah, I agree, I'll stop answering on this bug and the other about USE flag sorting.


>
> "The way the world saw this"? Further down, you've labelled half
> the voting users as ignorant because they don't agree with you on
> the point of use flag ordering.
>


'Depends what you mean by "ignorant". They are, as they don't (and can't) know that the new way is better, if they didn't test it, for enough time, if at all, when it is breaking the strict, fixed, alphabetic order. They are, when ignoring there own way of apprehending texts and lists, and basing their opinion on obscure feelings, which surely will change after some time of using the new way (again, it will not happen for all, as we all are different, but if you break the strict fixed alphabetic order for lists, there is no doubt most people will prefer the old way).


>
> That doesn't really give much weight to what you see as "the world".
>


Do you see fifty people, or even more, on a forum labeled "Portage & Programming", as the world?


>
> If you feel strongly about this, start a new topic in
> the forums and show that there are a substantial number of people that care
> about this.
> 


http://forums.gentoo.org/viewtopic-p-3055798.html


Cya.
Comment 11 email_deleted_GqKU 2006-01-31 02:56:46 UTC
Created attachment 78552 [details, diff]
Adds an option for displaying a plus ('+') symbol before activated USE flags to `emerge`

I added the option to `emerge`, the `emerge` man page and the `emerge --help` screen. It was quite simple, I should have done this sooner (and that's what I'll do if there is a next time...).

The display of the plus symbol is a non-default option, as I guess you won't include it otherwise, but I still think it is an error, as the --alphabetical USE flag (well, you properly advertised the change, so I guess it's ok).

The following might be added to the ebuild `pkg_postinst()` function:
###############################################################

einfo "Moreover, the plus ('+') symbol before activated USE flags"
einfo "has been removed. You may readd it by using the option:"
einfo "\"--display-plus-symbol-before-activated-use-flags\"."

###############################################################


The following might be added to the release notes:
###############################################################

* The plus ('+') symbol before activated USE flags has been removed. You
  may readd it using the emerge option:
  "--display-plus-symbol-before-activated-use-flags".

###############################################################


I guess you won't like the length of the emerge switch, and considering today consoles, it is indeed pretty long... anyone has another idea? (which still holds some precise meaning...).