Most of the time when I update a package with emerge -u, I dont want it added to the world file... Would it be possible to change the emerge behavior (as we have discussed) to not add already installed packages to the world file if the -u option is passed to portage. And maybe add a "add to world" option (--add-to-world) or something.... Or if that can't be done.. maybe a one letter shortcut for --oneshot..
*** This bug has been marked as a duplicate of 41407 ***
err this is not the same as 41407... its not about a shortcut, its about automated behavior...
The title of this bug is incorrect, but I was just about to file one with similar content... When you are updating an ebuild it should not be added to the world file. The current behavior breaks emerge depclean, because if I had emerge -u any of the dependencies of something I unmerged, then those deps won't be removed with depclean. When I use emerge depclean, I first have to edit my /var/cache/edb/world file and remove anything I don't think is something I want there... (guess) then I have to emerge depclean -p and verify that I didn't mess up, if I did, I re-add it to the world file and back and forth till I am satisfied. Using --oneshot is similarly tedious, but easy to forget. I would not have to do this if portage kept the world file clean as it should be. However, This does not mean that portage should not add any ebuilds into the world file while using -u because you could be installing a new ebuild and still pass the -u flag, and it would still install the new ebuild and all the deps. So, basically what portage should do is only add a package to the world file if it is not updating it and it was explicitly typed into the command line. Example time: $ emerge -up apollon [ebuild U ] kde-base/kdelibs-3.2.2 [3.2.1] [ebuild N ] net-p2p/gift-0.11.6 [ebuild N ] net-p2p/apollon-0.9.2 This should result in only apollon being added to the world file, not gift or kdelibs. $ emerge -up kdelibs [ebuild U ] kde-base/kdelibs-3.2.2 [3.2.1] kdelibs should not be added to world file in this example either, but in the next examples, it would be. $ emerge -up kdelibs [ebuild N ] kde-base/kdelibs-3.2.2 or $ emerge -p kdelibs [ebuild N ] kde-base/kdelibs-3.2.2 The only negative effect of changing this behavior of portage is emerge -u will not be as thourogh as it was, but this is the intended behavior of -u, and the purpose for -D. Thanks for reading, my long winded rant...
portage-2.0.51_pre9
Bug has been fixed and released in stable portages on or before 2.0.51-r2
Unfortunately this does not seem to be fixed. luna ~ # emerge -u gentoolkit -a Calculating dependencies ...done! [ebuild U ] app-portage/gentoolkit-0.2.0_pre10-r1 [0.2.0_pre10] <SNIP> >>> Recording app-portage/gentoolkit in "world" favorites file... If I understand evertything right, this should not happen as to Tonys proposals. It would be nice if someone could REOPEN this bug and have a look at it. Thanks. take care, have fun /christian
Damn, I knew I'll forgot something: This is with "Portage 2.0.51-r3" take care, have fun /christian
Reopening as I tend to agree with this, but need to get some confirmation first.
personally i'm against this behavior. if we really want something to be outside world file, we can use --oneshot (i'm used to use that option whenever i want to recompile something with changed C*FLAGS/USE, no matter if package was or wasn't in world earlier). additional i have to say that i've never use -u option for only one package (AFAIR) well - you may now say that's unimportant from my point of view, but actually it itsn't. IMO it'd make portage bahavior hard to understand in some situations. i don't understand why you want to connect two options, which are really for two diffrent things. lets leave --oneshot for packages we don't want in world and --update for updates (well - it isn't in fact for updates, so it's already hard to undestand what it's for for new users). what i wanted to say - if you'll start to combine diffrent options together or make their behavior depend on what's installed in system/written in world file, then portage would start to transform from pretty simple tool (well - it's not such simple already:>) into hard-to-undestand-monster just my private opinion....
Hi Marcin, > if we really want something to be outside world file, we can use --oneshot > (i'm used to use that option whenever i want to recompile something with > changed C*FLAGS/USE, no matter if package was or wasn't in world earlier). On the one hand I'd second that. (See below for the other hand) > IMO it'd make portage bahavior hard to understand in some situations. I cannot think of a situation that would be hard to understand. What would that be for example? > i don't understand why you want to connect two options, which are really > for two diffrent things. lets leave --oneshot for packages we don't want in > world and --update for updates (well - it isn't in fact for updates, so > it's already hard to undestand what it's for for new users). And here comes the other hand: Running 'emerge --update <packagename>' gives the impression, that an update is run. And I have absolutely no idea, why only updating packages should change their worldfile status at all! Picking up your phrasing I think we should say: "Running 'emerge <packagename>' should touch the worldfile, and all other actions should keep away from /var/lib/portage/world' Because the worldfile is for packages emerged explicitly, and there is no way to more 'explicitly' merge a package than the above. I'm open to all discussions on that, and if we come to the conclusion, that current state is good, I'm OK with that. But in that case I think the portage behaviour should be clarified. take care, have fun /christian P.S.: I guess, that more then 75% of the gentooers worldfiles are broken wrt having no (unwanted) dependencies in it. Additionally I think, that there are many people, that never used the --depclean option from portage at all, which is actually the only basic system cleaning option from portage, so that people really do not know, that their worldfile is borked. That bigass warning of --depclean scares peple away :-). But that is another story!
So, whats up with this nice bug? Long time no update :-) take care, have fun /christian
Next portage release will be always add to world unless --oneshot is specified.
*** Bug 69287 has been marked as a duplicate of this bug. ***
*** Bug 80406 has been marked as a duplicate of this bug. ***
*** Bug 85855 has been marked as a duplicate of this bug. ***
*** Bug 86632 has been marked as a duplicate of this bug. ***
*** Bug 91297 has been marked as a duplicate of this bug. ***
I use portage 2.0.51.19 and have been bitten by this bug. (I know it is supposed to be fixed in the next version) I _always_ run "emerge -avDut --newuse {system,world,pkg_name}" even when I'm emerging something for the first time because I never read anything that said not to. Anyway, the way that it gets me is when I do an esync it will list all the packages that I have installed that have updates available (with [ U] ???) but when I try to update world the packages don't come up. This happens even though I explicitly emerged them on the command line and did everything right (except added the -u flag). I double checked this behavior by backing up a version of sudo and removing it from world. Then I did an "emerge -avDut --newuse app-admin/sudo" and it updated sudo fine but didn't add it to the world file. I then backed up again, adjusted the world file and then "emerge -avDt --newuse app-admin/sudo" and it got added to the world file. The question now is how many packages my world file is missing. Comparing it to the output of /usr/lib/portage/bin/regenworld indicates that it is missing quite a few. I guess that esync is looking for packages in /var/log/emerge.log instead of world but I'm not sure about that. This was reported by me as bug #89472 and I have changed it from "Resolved Invalid" to "Closed" since jstubbs has indicated that the next version of portage will add everything explicitly mentioned on the command line to world unless the --oneshot option is used.
Fixed on or before 2.0.51.22-r1
Looking through the batch of bugs, I'm not sure that some of these are actually fixed in stable. Others, the requirements have possibly changed after the initial fix was committed. If you think this bug has been closed incorrectly, please reopen or ask that it be reopened.
