Admittedly, an alternate summary could be "I can't remember to add -1 when I'm upgrading stuff." But, why should I have to? Is there any situation in which the current behavior is desirable? As I see it, * If a package is in world, updating it should leave it there. * If it's not in world, I don't want it there. I just want the package updated. * Adding an unwanted package does more harm than not adding a wanted one. * * And you wouldn't use --upgrade to install a wanted package anyway. This is resolved: fixed in bug 48181, but that was a while ago. I'm guessing something changed? Anyway, I think we should default to safety.
I agree to your proposition.
We've tried this in the past and ended up reverting it because of complaints (see bug 190781). Generally, I prefer for options to have relatively pure meaning, since giving them multiple meanings tends to lead to conflicts when the user wants one of the meanings and not another. As an alternative, I'd suggest to set EMERGE_DEFAULT_OPTS="--select=n", and use --select when you want something added to the world file (see bug 287869).
(In reply to comment #2) > We've tried this in the past and ended up reverting it because of complaints > (see bug 190781). There you have it: I complain about reverting the changes ;) > Generally, I prefer for options to have relatively pure > meaning, since giving them multiple meanings tends to lead to conflicts when > the user wants one of the meanings and not another. So you are saying, that we basically all agree ? I think, Michael Orlitzky has a point: * either you _have_ a packet in the world list, then changing --upgrade behaviour shouldn't change anything * if a packet is not in the world list, then --upgrade should not add it automatically. However, this is what it currently does - and I'm not really happy with it. > As an alternative, I'd suggest to set EMERGE_DEFAULT_OPTS="--select=n", and use > --select when you want something added to the world file (see bug 287869). This is no proper workaround, because I would have to add each NEW packet explicitly to the world list.
(In reply to comment #3) > > Generally, I prefer for options to have relatively pure > > meaning, since giving them multiple meanings tends to lead to conflicts when > > the user wants one of the meanings and not another. > > So you are saying, that we basically all agree ? I don't think so. When I say that I want --update to have pure meaning, I mean that I don't want it to imply other options such as --oneshot.
(In reply to comment #4) > (In reply to comment #3) > > So you are saying, that we basically all agree ? > > I don't think so. When I say that I want --update to have pure meaning, I mean > that I don't want it to imply other options such as --oneshot. You know, from a users point of view, it's just the opposite: a casual user like me is surprised to see 'emerge -u' to perform another operation in background (namely adding the package to the world list). I guess, that's the crux of this discussion. Can you explain the benefits of the current --update behavior ? TIA
Rather than pollute the meaning of existing options, I think it would be better to add new targets that combine various options together. For example, see the --upgrade target that's been discussed here: http://archives.gentoo.org/gentoo-dev/msg_111f02e444ed34d452ae9d367423af4a.xml
(In reply to comment #6) > Rather than pollute the meaning of existing options, I think it would be better > to add new targets that combine various options together. Thanks for the explanation, Zac. I understand and take this as valid point. However, the current behavior 'feels' inconsistent to me: - when I do emerge --update xyz, then xyz will be added to the world list - when I do emerge --update abc which implicitly updates xyz, only abc is added Nevertheless, I totally agree that breaking existing behavior is seldom a good idea. > For example, see the > --upgrade target that's been discussed here: > > http://archives.gentoo.org/gentoo-dev/msg_111f02e444ed34d452ae9d367423af4a.xml Uh - please don't. emerge is complicated enought IMHO. On Debian systems, I confuse --update and --upgrade regularly. Adding two almost equivalent operations makes no sense if you asked me.
(In reply to comment #7) > However, the current behavior 'feels' inconsistent to me: > - when I do emerge --update xyz, then xyz will be added to the world list > - when I do emerge --update abc which implicitly updates xyz, only abc is added The purpose of the world list is to serve as a set of root nodes in the dependency tree. Since the abc was not given as an argument, and abc is reachable as a dependency of xyz, it would be redundant to add abc to the world file. As dependencies change, obsolete dependencies are removed by emerge --depclean. If we added all dependencies to the world file, then you'd end up with lots of obsolete dependencies installed because they wouldn't be removed by emerge --depclean.
(In reply to comment #8) > (In reply to comment #7) > > However, the current behavior 'feels' inconsistent to me: > > - when I do emerge --update xyz, then xyz will be added to the world list > > - when I do emerge --update abc which implicitly updates xyz, only abc is added > > The purpose of the world list is to serve as a set of root nodes in the > dependency tree. Since the abc was not given as an argument, and abc is > reachable as a dependency of xyz, it would be redundant to add abc to the world > file. As dependencies change, obsolete dependencies are removed by emerge > --depclean. If we added all dependencies to the world file, then you'd end up > with lots of obsolete dependencies installed because they wouldn't be removed > by emerge --depclean. Yes! But abc _is_ either already in the world list, or it is itself a dependency. In the latter case, it would NOW be added to the world list. In practice, I do 'emerge -1u' relatively often, since I want to update depending libraries, but do not want to add them to the list. My point is that it is inconsistent to me. However, we need not to discuss this further -- I will have to live with that ;) Thanks again.
I started a rather large discussion about this on gentoo-user. There are people who defend the current behavior, but the only reason (seriously) I've heard is that "Zac must have had a good reason to do it." I do see the benefit of having a logically consistent emerge command, where in some sense each option is "pure." However, the current behavior does *real* damage to my systems, and to me, that's worse than the loss of a little warm-fuzzy that might have come from the old behavior. My situation is that I have some packages installed that need to be installed, but I don't know their names. Yes, I could have solved this by being smarter six years ago. But I didn't document it because back then, in part because --update did the right thing and it was difficult to pollute the world file accidentally. Now, nobody knows what they are. But they're installed. The current --update behavior prevents me from cleaning out my world file. Merely the threat of having accidentally left out --oneshot some time in the past (which I /know/ I've done) means that some packages are probably in world for the wrong reasons. But now, I don't know which ones are there because they need to be there! At the moment, there's no urgent danger. However, these are servers that I expect to be around for ten more years. If a rogue package gets added every few weeks, it's not a problem next year, but it could be trouble eventually. This problem is avoidable in the future (only on new machines!) with sets, custom ebuilds, EMERGE_DEFAULT_OPTS, or even good documentation. But to do any of those, you have to know about the problem before you install any packages. I have a feeling most people don't do those things, and accidentally trash their world file with --update before they've got their heads on straight. On most machines, it's no big deal -- you just remove stuff until your system breaks, and then you put it back. But there are those (alot?) of us who use gentoo on critical systems, and the current --update behavior will come back to haunt others like me in the future.
(In reply to comment #10) > the current --update behavior will come back to > haunt others like me in the future. You seem to be under the impression that the --oneshot and --update behaviors are intrinsically related in some way. You may like to use them together, but that does not mean that they must be tied together for all users. I'd suggest to set EMERGE_DEFAULT_OPTS="--select=n", and use --select when you want something added to the world file (see bug 287869). Also, it's worth mentioning the possibility of adding new targets that combine various options together. For example, see the --upgrade target that's been discussed here: http://archives.gentoo.org/gentoo-dev/msg_111f02e444ed34d452ae9d367423af4a.xml
(In reply to comment #11) > (In reply to comment #10) > > the current --update behavior will come back to > > haunt others like me in the future. > > You seem to be under the impression that the --oneshot and --update behaviors > are intrinsically related in some way. You may like to use them together, but > that does not mean that they must be tied together for all users. > I think they *should* be linked, but that's not really the issue. The problem is that many users are essentially /born/ thinking that --update should not add packages to world, and without a deeper investigation, those users can permanently break their world file. The way we see it (if I can pretend to speak for everyone who prefers the old behavior), it's incorrect to assume that updating a package and adding it to the world file are somehow intrinsically linked. The EMERGE_DEFAULT_OPTS solution is silly: I shouldn't have to pass --dont-hurt-me to every emerge command. Furthermore, you're offering a vaccine to people who won't know the disease exists until after they have it. But ultimately, a semantic argument is pointless: the new way is likely to break systems, the old way is not.
(In reply to comment #12) > I think they *should* be linked, but that's not really the issue. The problem > is that many users are essentially /born/ thinking that --update should not add > packages to world, and without a deeper investigation, those users can > permanently break their world file. I'd say that they're likely to accidentally add packages to the world file regardless of the --update behavior. So, your suggested solution does not cure the problem. It only masks the problem for commands that include the --update option.
(In reply to comment #13) > (In reply to comment #12) > > I think they *should* be linked, but that's not really the issue. The problem > > is that many users are essentially /born/ thinking that --update should not add > > packages to world, and without a deeper investigation, those users can > > permanently break their world file. > > I'd say that they're likely to accidentally add packages to the world file > regardless of the --update behavior. So, your suggested solution does not cure > the problem. It only masks the problem for commands that include the --update > option. How? Before the change, the only command that I'd ever used that would add a package to world was 'emerge <package>'. I ran that maybe 20 times while setting up a server, and very rarely thereafter. Routine maintenance consists entirely of emerge --update, revep-rebuild, depclean, and eix-test-obsolete. For my use case, the old behavior made mistakes ~100% less likely.
(In reply to comment #14) > For my use case, the old behavior made mistakes ~100% less likely. Like you said, that's for your use case. However, we don't know how it will affect the use cases of random users. Some of them may expect packages to be added to the world file with --update, and may cause "damage" to their systems if we change the default.
(In reply to comment #15) > (In reply to comment #14) > > For my use case, the old behavior made mistakes ~100% less likely. > > Like you said, that's for your use case. However, we don't know how it will > affect the use cases of random users. Some of them may expect packages to be > added to the world file with --update, and may cause "damage" to their systems > if we change the default. But there is no damage in that case, that's my point. Nobody uses --update to install new packages. Even if someone does, portage has the ability, through --depclean, to let him know that he made a mistake.
(In reply to comment #16) > But there is no damage in that case, that's my point. The idea of "damage" is subjective. For some users in some cases, "damage" can be a package omitted from the world file. For other users in other cases, "damage" can be an unwanted package added to the world file. > Nobody uses --update to install new packages. That's not necessarily true. I've heard of people who use `emerge -avu <atom>` to check if a package is installed before they decide to install it and have it added to their world file. > Even if someone does, portage has > the ability, through --depclean, to let him know that he made a mistake. Again, it's subjective. It can be considered "damage" both when wanted packages are omitted and when unwanted packages are added.
(In reply to comment #17) > > Again, it's subjective. It can be considered "damage" both when wanted packages > are omitted and when unwanted packages are added. But portage can only fix one of them! (If you just don't want to fix it because you don't want to change it again, I understand, but,) I don't even see any of the complaints about the old behavior that you mentioned. There seems to be no better argument for the new behavior than "I think that's how it should be." This is in contrast my very real case where the new behavior breaks stuff.
The main reason I don't want to change it is that I prefer for options to have pure meanings that are orthogonal to each other, since making them a mix of orthogonal meanings tends to lead to conflicts when the user wants one of the meanings and not another.
Alright. I've made every argument I've got.
