Some background information:
Starting with the 2.2 series[1] portage supports the concept of Package sets. These include the well-known "system" and "world" as well as any number of user-defined lists and several other dynamic sets (e.g. "security" or "everything"). Package sets can contain both standard atoms (e.g. >=category/package-2.6) and other sets, and can be used as arguments to emerge (other use cases will be implemented later).

Now a question that has come up recently is if installing a package set should also add it to the "world" set by default. For example assuming you have a user-defined package set S containing packages A, B and C (which are not in "world"), should emerge @S insert S into the "world" set, so that a subsequent emerge -uD @world would also update A, B and C whenever possible, or would you prefer it to be not included, so for updating those packages you'd have to run a separate emerge -u @S.

Two things should be noted here:
a) while --oneshot can be used to not add something to "world" there is no opposite option to force something being added
b) "system" is no longer included in "world" unconditionally, yet a simple emerge --noreplace system will add it back with the current default behavior

[1] A first test release of 2.2 is available in the tree for those who really want to test it. Please note however that it is still in development, so don't complain if things break eventually (but report such bugs in #gentoo-portage)

I voted for "yes but with (persistant) opt-out". This is IMHO the best way to stay close to current behaviour of portage but also gives the chance to change that if desired by the user..._________________The manual said "Requires Windows10 or better" so I installed GNU/Linux...

I voted No. If sets are stuff that gets added to world (yes I know about -1) they might as well just be added at the command-line and then tracked as part of world. The point being that once it's in world, it doesn't need to be tracked separately.

I see sets which include stuff not in world as much more useful, eg himerge and xmonad and all their deps would be a haskell set (on my machine) meaning I could update those as and when I needed to, if there were some issue.

Personally I'd just revert one aspect of the behaviour, so that emerging world would also do the system set (and make it so sets were not installed to world when emerged.) I think I'd also make it so that only the installed ones were updated, so that I could use sets defined by devs even if I didn't have, or want, all the packages listed.

Maybe an -i flag would be good to install stuff to world; it's what we use in update since it's more common that I emerge stuff to update dependencies than actually install a package. (So update effectively does the opposite from emerge, oneshotting by default; that's definitely more in tune with an updater ofc ;) I still wouldn't use that to install a whole set to world though.

It feels more logical that there is a default, overarching set that will include everything.

Since we already have 'world' set, I would think the most natural progression would be to keep that as a superset of everything (excluding 'system'), and that other sets would include only user-defined parts of the 'world'.

I'm of course assuming that a package can be a part of several different sets simultaneously.

If someone wants to have a 'pseudo-world' that has everything except some particular packages, they could copy duplicate 'world', and then prune it to their liking.

This would also ensure that no packages become orphaned from rearrangement of user-defined sets.

[edit:] Of course a persistent opt-out should be included. This is, after all, Gentoo._________________Gnome:
1. A legendary being.
2. A never ending quest to make unix friendly to people who don't want unix and excruciating for those that do.

I voted "yes (with persistent opt-out)" because I see user-defined sets as useful even (or especially) if they generally go into world as well.

I recently ran into a problem where ppp wouldn't compile, which caused kppp to have unmet dependencies, propagating to kdenetwork-meta, kde-meta, and finally world. I don't even use ppp and it's only installed because it's a dependency of kde-meta. Someone suggested that I remove kde-meta and instead install the 12 or so packages it installs, plus whatever else from kdenetwork-meta I needed/wanted, but that seemed to me an awful lot of work for a desktop environment that I use once every three or four months (I typically stick with Gnome). I wanted to retain the ability to unmerge kde easily (by, for example, emerge --unmerge kde-meta && emerge --depclean -a) and if I couldn't have that, I was probably going to just unmerge KDE and forget about it. (I monitor my --depclean list to keep my system from getting stale packages.)

If I could have defined my own "kde-meta-meta" package (as, for example, a new user set), I could have retained the ability to easily merge/unmerge the set of KDE packages I have use for, while being able to customize it to have only those packages I need. Without an easy way to add it to world, though, its utility goes way down. I don't see myself using these sets for much else, so for me the natural way to use it would be to have it added to world by default like almost everything else you emerge, and have --oneshot be to override that.

Of course, if it's easy, persistent opt-out is a good thing too. Gentoo is about empowerment._________________Of course, I've been wrong before and I'm sure I'll be wrong again. So this may be one of those times.

What I'd personally do is create another set in addition to world and system, named, say, universe, to which all installed packages are added. This would facilitate updating the system as well: emerge -u universe would bring every single package on the system up to date.

How I'd do it:

system is not part of world by default, but can be added through --noreplace. Depclean should always ignore system. The main reason for adding system to world is for updating.

world holds the packages the user has explicitly installed.

universe holds all packages. There would be no opt-out for it.

On a related note, I'd also love to see a --replace option for emerge, which automatically removes the matching packages from world.

What I'd personally do is create another set in addition to world and system, named, say, universe, to which all installed packages are added. This would facilitate updating the system as well: emerge -u universe would bring every single package on the system up to date.

Interesting: that would be all stuff in /var/db including things which depclean would remove?

Quote:

How I'd do it:

system is not part of world by default, but can be added through --noreplace. Depclean should always ignore system. The main reason for adding system to world is for updating.

world holds the packages the user has explicitly installed.

universe holds all packages. There would be no opt-out for it.

Apart from the universe set, that's what we have now. System packages aren't listed in world, but they get updated when world does (which makes sense to me.) What is the reasoning behind changing that behaviour? After all, system can already be updated separately, and it doesn't seem wise to update world without an updated system set as well. (If that is desired, I don't think it should be the default.)

Quote:

On a related note, I'd also love to see a --replace option for emerge, which automatically removes the matching packages from world.

Why not just emerge -Cq it? emerge --replace foo bar where foo is installed instead of bar sounds nice (especially for virtuals.) I guess you mean remove it from world, but don't uninstall it? I can see how to do that with a simple bash fn, eg:

Code:

replace() { sed -i "\@$1@d" /var/lib/portage/world; }

but that's not portable (would need checking wrt slots as well, so don't use it ;)

What I'd personally do is create another set in addition to world and system, named, say, universe, to which all installed packages are added. This would facilitate updating the system as well: emerge -u universe would bring every single package on the system up to date.

Interesting: that would be all stuff in /var/db including things which depclean would remove?

Yes, but in the format of a simple list rather than a directory structure. It would provide a portable, persistent way to update everything, and could be a handy emergency fallback for those people who delete their /var/db.

steveL wrote:

Quote:

How I'd do it:

system is not part of world by default, but can be added through --noreplace. Depclean should always ignore system. The main reason for adding system to world is for updating.

world holds the packages the user has explicitly installed.

universe holds all packages. There would be no opt-out for it.

Apart from the universe set, that's what we have now. System packages aren't listed in world, but they get updated when world does (which makes sense to me.) What is the reasoning behind changing that behaviour? After all, system can already be updated separately, and it doesn't seem wise to update world without an updated system set as well. (If that is desired, I don't think it should be the default.)

It may be a better idea to handle it the way it's done now, although perhaps with a way to exclude system from from world temporarily, in case you want to just update those packages that you deliberately installed.

steveL wrote:

Quote:

On a related note, I'd also love to see a --replace option for emerge, which automatically removes the matching packages from world.

Why not just emerge -Cq it? emerge --replace foo bar where foo is installed instead of bar sounds nice (especially for virtuals.) I guess you mean remove it from world, but don't uninstall it? I can see how to do that with a simple bash fn, eg:

Code:

replace() { sed -i "\@$1@d" /var/lib/portage/world; }

but that's not portable (would need checking wrt slots as well, so don't use it

Yep, I mean to remove it from world without uninstalling. Removing a package from world and letting depclean determine when it's safe to uninstall is a bit friendlier than removing it and having it reinstalled during a revdep-rebuild. It's basically a lazy man's way of saying "I don't want it, but keep it until it's not needed any more". It also saves a fair bit of work if you forget --oneshot when installing a dependency manually.

What I'd personally do is create another set in addition to world and system, named, say, universe, to which all installed packages are added. This would facilitate updating the system as well: emerge -u universe would bring every single package on the system up to date.

Actually, such a set already exists by default in 2.2, just that it's named "everything" atm.

Apart from the universe set, that's what we have now. System packages aren't listed in world, but they get updated when world does (which makes sense to me.) What is the reasoning behind changing that behaviour? After all, system can already be updated separately, and it doesn't seem wise to update world without an updated system set as well. (If that is desired, I don't think it should be the default.)

Well, there have been several requests to update world without system in the past. Also it's now possible to list multiple sets as emerge arguments, so

Code:

emerge -uD @system @world

would be the equivalent of the old behavior, or people can just run

Code:

emerge --noreplace @system

to reinclude it and not worry about anymore (with the current behavior that is).

The reason being, if there is a new dynamic package set called "everything" and user defined package sets, it seems that "world" may become less useful than it was. I guess it would more accurately be called "the rest of the world", as it would only catch packages that are not specifically added to a user defined set.

Well, there have been several requests to update world without system in the past. Also it's now possible to list multiple sets as emerge arguments, so

Code:

emerge -uD @system @world

would be the equivalent of the old behavior, or people can just run

Code:

emerge --noreplace @system

to reinclude it and not worry about anymore (with the current behavior that is).

Ah OK so we get @world and @system separately, both for current emerge world, and @everything for anything installed. Makes sense. Would emerge -uD @system @world not add the system set to world then? That would allow the granularity I was after; nice one :-) Just want to make sure that emerging @system isn't going to add it all to world by default.

Interesting poll. I'm really not sure. Consider the following three usage scenarios:

I upgrade my Gentoo boxes very regularly, once or twice a month. Quite often, however, I'd like to exclude the kernel and all packaged kernel modules (nvidia-drivers, ivtv, etc.) from that. Nevertheless being able to simply type "emerge -uDpv world" would be a great thing. The SET feature seems ideal for that purpose, and I would prefer to not have the "kernel" set in world by default: I'd vote NO.

Another similar case is one of my machines which runs quite a number of PHP-based webapps: typo3 (well, bad example, it's not in portage and actually an installation from sources - but imagine it was from the webapps overlay ), Joomla, phpmyadmin, mediawiki, wordpress... I'd would like to be able to exclude that "webapps" set from world and not mess around with re-linking and virtual hosts configuration on each world upgrade. So again, I'd vote NO.

Now I'll try to imagine a counter-example. A convincing usage of world-contained sets would be to manage overlays more easily. AFAIK, layman can be used to update (i.e., sync) the overlay, but it cannot be used to upgrade "all the packages currently installed from that overlay" with one command. Here the sets would come in handy. They would allow me to very easily upgrade, lets say, all my packages from the proaudio overlay on an otherwise stable system. On the other hand, if I decide to upgrade world, I'd like to have the proaudio-overlay included, so for this third scenario, I'd vote YES.

Just want to make sure that emerging @system isn't going to add it all to world by default.

That would indeed be crazy! :D

Yeah ;-) but I'm pretty sure that's what the current situation is?

cjubon wrote:

Interesting poll. I'm really not sure. Consider the following three usage scenarios:

I upgrade my Gentoo boxes very regularly, once or twice a month. Quite often, however, I'd like to exclude the kernel and all packaged kernel modules (nvidia-drivers, ivtv, etc.) from that. Nevertheless being able to simply type "emerge -uDpv world" would be a great thing. The SET feature seems ideal for that purpose, and I would prefer to not have the "kernel" set in world by default: I'd vote NO.

Another similar case is one of my machines which runs quite a number of PHP-based webapps: typo3 (well, bad example, it's not in portage and actually an installation from sources - but imagine it was from the webapps overlay ;-)), Joomla, phpmyadmin, mediawiki, wordpress... I'd would like to be able to exclude that "webapps" set from world and not mess around with re-linking and virtual hosts configuration on each world upgrade. So again, I'd vote NO.

Now I'll try to imagine a counter-example. A convincing usage of world-contained sets would be to manage overlays more easily. AFAIK, layman can be used to update (i.e., sync) the overlay, but it cannot be used to upgrade "all the packages currently installed from that overlay" with one command. Here the sets would come in handy. They would allow me to very easily upgrade, lets say, all my packages from the proaudio overlay on an otherwise stable system. On the other hand, if I decide to upgrade world, I'd like to have the proaudio-overlay included, so for this third scenario, I'd vote YES.

Cheers, cjubon

1) I'd use module-rebuild; update wraps that (so update -W will rebuild the modules, using the usual nice filtering.)
2) Only issue with not having those in world is that emerge --depclean will get rid of them.
3) Hmm interesting; would definitely be worth having a way of emerging stuff from an overlay. Wrt to the set handling, tho, you could just emerge @world @audio atm, or emerge @audio would currently install the set to world (if it's changed, then emerge -i @audio or the equivalent would add it to world) and from there on in it would be tracked as part of world. This just seems to me like a not very useful thing to do. After all, if you want it tracked as part of world, why not just add the lot to world in the first place?

I think sets are useful, and it's good the mechanism is now in portage; I don't think the usage has quite been worked out yet, tho, and I'm glad the devs are asking us how we'd want to use them; so thanks, Genone. For my part I'd like them to be a subset of everything that we track, and can update (along with usual tree options like -uDN) separately. If I want to add a list of packages to world, that's easy enough already.

Guess I wasn't explicit enough about this: when I was talking about "adding a set to world" I was always referring to adding the setname (copy-by-reference), not adding the packages contained in the set (copy-by-value)

Guess I wasn't explicit enough about this: when I was talking about "adding a set to world" I was always referring to adding the setname (copy-by-reference), not adding the packages contained in the set (copy-by-value)

Yeah, sorry I should've checked that with you. Doh ;p I like it a lot now that I've thought about, although I have to say I'd still prefer default no with opt-in. Whatever you decide on, i'm sure we'll able to configure it to our liking. Thanks for the hard work you've put into getting 2.2 out: and well done.

I vote for "always add", because I like the current meaning of "world". For scenarios like "upgrade without @system" I suggest that the user maintain a package set like @myworld. The world file could then consist of the two lines @myworld and @system

FF,

Daniel_________________Logic clearly dictates that the needs of the many outweigh the needs of the few. - Spock
The needs of the one outweigh the needs of the many. - Kirk
I refuse to let arithmetic decide questions like that. - Picard

I vote for "always add", because I like the current meaning of "world". For scenarios like "upgrade without @system" I suggest that the user maintain a package set like @myworld. The world file could then consist of the two lines @myworld and @system

FF,

Daniel

Totally agreed, that is my understanding of the meaning of world in the context of Gentoo.
Whatever sets the user might create, _world is the sum of them_ so that 'emerge world' still carries the same meaning in its metaphor, that is:"upgrade everything from toes to head".
(I really like this metaphor by the way: i personally think it is the most elegant compared to apt this upgrade that..)

This is a really subjective opinion of course._________________no way to happiness, happiness is the way