| Summary: | Since 2.2, portage does not treat system as part of world | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Zdenek Behan <rain> |
| Component: | Core | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | dabbott, darkside, esigra, esqualante, john_r_graham |
| Priority: | High | Keywords: | InVCS |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 144480, 210077, 288499 | ||
|
Description
Zdenek Behan
2009-04-17 00:59:55 UTC
This is intended behavior, unfortenetly I cannot find the docs right now that explicitly say this. (In reply to comment #1) > This is intended behavior, unfortenetly I cannot find the docs right now that > explicitly say this. Well, it sure seems like a big change. Would be worth mentioning in the manual with a huge ! next to it, because it's probably going to also affect all people doing "emerge -uD world". If i understand this correctly, this command will stop upgrading things like baselayout and openrc in 2.2 because they're not part of the world anymore. Unless you explicitly put them to the world file. You can add system to world if you want the old behavior. I'm not sure if there's a "right" way to do it, but you can add 'system' (or is it '@system'?) to /var/lib/portage/world_sets. (In reply to comment #3) > You can add system to world if you want the old behavior. I'm not sure if > there's a "right" way to do it, but you can add 'system' (or is it '@system'?) > to /var/lib/portage/world_sets. Well, as for me, i can manage. Adding @system to world_sets works. But it has to be added manually, just "emerge @system" does not seem to add it automatically, unlike with other sets. Another way is to simply always use "world system" as package specification. Neither of those is very user-friendly, in particular with respect to the previous behaviour. I'm just curious what's the reason for such a drastic change. I can imagine a lot of users being confused and a lot of systems not updating correctly as a result of this. And that certainly does not sound like intended behaviour to me. Current versions of the portage-2.2_* ebuild add @world to world_sets during upgrade. If you didn't get it then that means you started using portage-2.2 before that was added to the ebuild. It's only done when upgrading from portage-2.1.x since we don't want to add it to world_sets in cases when the user has intentionally removed it. (In reply to comment #5) > Current versions of the portage-2.2_* ebuild add @world to world_sets during > upgrade. If you didn't get it then that means you started using portage-2.2 > before that was added to the ebuild. It's only done when upgrading from > portage-2.1.x since we don't want to add it to world_sets in cases when the > user has intentionally removed it. Hmm, ok. I find that highly nonintuitive and confusing though. If you wanted to separate world from system, it would be IMO much better to define a new set, called fe. @userpackages instead of world, and make world just "virtual" pulling in @userpackages and @system instead. Users who wish to install just world without system would use @userpackages. That 1) does not rely on any configuration specific to this version, 2) is fully backwards compatible with empty portage configuration world/world_sets. This solution of modifying configuration on upgrade can be easilly called fragile, for example for people who delete their world_sets file by accident and need to reconstruct it. Just my opinion, though, thank you for the explanation, i added @system manually. system not being part of world is highly confusing, it's somehow like defining antarctica not being part of the earth. What's the single one 'virtual' to use for simply everything? Since I'm using portage 2.2 since _rc15 or so there's no @system set in my world_sets. (In reply to comment #7) > system not being part of world is highly confusing, it's somehow like defining > antarctica not being part of the earth. If feel sort of the same way. I'm going to ponder this for awhile. (In reply to comment #7) > system not being part of world is highly confusing, it's somehow like defining > antarctica not being part of the earth. /me +1, if that isn't obvious from what i wrote above. :P (In reply to comment #6) > Hmm, ok. I find that highly nonintuitive and confusing though. If you wanted to > separate world from system, it would be IMO much better to define a new set, > called fe. @userpackages instead of world, and make world just "virtual" > pulling in @userpackages and @system instead. Users who wish to install just > world without system would use @userpackages. I think I'll call the new set @selected. That name will be consistent with the name of the --deselect option that I've planned, described in bug #259994, comment #4. Bah, it only seems weird because it's always been the other way.
The analogy of Anarctica not being part of the Earth is flawed. @world consists of everything in /var/lib/portage/world{,_sets} where @system consists of the packages contained in 'packages' in the profile. How does the definition of @system fit into the definition of @world?
(In reply to comment #11) > Bah, it only seems weird because it's always been the other way. ...which is a good enough argument for it staying that way, IMO. Honestly, i believe that world being everything is the use case for 99.9% of the users. I've been doing a lot of crazy stuff with my systems and never felt the urge to not update system, yet update world packages. > The analogy of Anarctica not being part of the Earth is flawed. @world consists > of everything in /var/lib/portage/world{,_sets} where @system consists of the > packages contained in 'packages' in the profile. How does the definition of > @system fit into the definition of @world? The initial logic of "world" being just a bunch of packages listed in some file is flawed in the first place. The world file is not really meant to be edited by hand (although people do it), and as such, the simple user should not be aware of its existence or ever touch it. And in such user, the "world" should basically invoke a feeling of everything there is. At least it always did in me, until i started messing with it. The world file should have been called "selected" since portage v1.0 and you wouldn't be having this dilemma right now. I think that a very important use case for exclusing @system from @world is to perform an efficient recompile of your whole system with (for instance) a new compiler release *without* a lot of redundant recompiles. Zach, is that not the case? Also, I tend to agree with Andrew. A rose by any other name does *not* always smell as sweet. @selected is hideously nonintuitive. - John (In reply to comment #13) > I think that a very important use case for exclusing @system from @world is to > perform an efficient recompile of your whole system with (for instance) a new > compiler release *without* a lot of redundant recompiles. Zach, is that not > the case? As i stated above, on my example system, those packages were left out from -e world: "gzip tar iputils openssh wget baselayout busybox gawk groff kbd less man man-pages man-pages-posix module-init-tools openrc sysvinit util-linux which make patch procps psmisc virtual/init virtual/pager" Most of those packages are tiny, very tiny. And note that both glibc and gcc (the biggest meanest animals of the whole @system) were dragged into the world as a dependency anyway. In fact _most_ of the ~80 packages considered part of system were dragged in as dependencies. The packages mentioned above rebuild on my system within approximately 20 minutes, compared to the day and half of rebuilding the rest. If the intent is being effective, then you'd have to manually go and kill a lot of dependencies on system packages, to make sure they don't belong to the world. This is fixed in svn r14614. Sorry to those who don't like it. We can't always please everyone. This is fixed in 2.1.7.2 and 2.2_rc47. |
