World set vs world file: Why so nonintuitive?

[szatox]

So you're suggesting something like "world" for 3, but something like "selected" for 1 and 2.

Uhm.... Isn't @selected a temporary set used internally by portage? I think I saw it (or something similar) pop out during some of the more complicated updates.
Could have something to do with rebuilding shared libs.

[psycho]

OK...so definitely not "selected", then. I was just running with this wording...

3. world set, that is the union of the selected, system and profile sets.

and the context of "user selected packages" in point 1. I guess it could be called almost anything other than "world", to address qsmodo's concern: the user_packages file or the explicit_emerges file or whatever. Personally I'm happy with world.

[Genone]

I think you missed the point, which is: The world file is for user selected packages, while the world set contains all the packages. This is counterintuitive.

Yes and no. Thing is, originally portage only had "system" and "world" and no general concept for package sets. Back then, "world" was defined to include "system" to simplify system updates. When package sets were implemented, "@world" was actually redefined to not include "@system" by default anymore, and a new "@everything" set with the old behavior was added. But most people got confused by that change due to their established routines, so the behavior was reverted and a new "@selected" set was added to only include packages listed in the world file.

Keep in mind that package sets are fully customizable using sets.conf, so you can redefine @world to anything you like

[psycho]

I was way behind. Now I get it: qsmodo is looking at the official set names. There *is* a @selected set that I've somehow never noticed and that corresponds to the world file, so it would indeed make more sense for that file to be called selected. Having two different sets named "selected" and "world", and then having the "world" file list the packages in the "selected" set rather than the "world" set, is indeed somewhat bizarre from a newcomer's perspective. I'm so used to the world file's role in defining my @world set that I think of this relationship as obvious and intuitive, but it really isn't, in the context of the package set names listed on the wiki: I can see how, for someone trying to make sense of the terms on that page, it is quite a confusingly inconsistent use of the term "world".

Oh well. My boxes still seem to be chugging along quite nicely, despite their @selected packages being listed in a file named world, and their @world packages including a whole lot more than the packages in that world file. I don't think they'll lose any sleep over it so I won't either...and I'm not going to get myself out of sync with the normal usage by redefining the sets locally, though it's nice to know we can do that. Obviously I didn't pay enough attention when package sets were introduced (I basically just ignored them, continuing to refer to world rather than @world, since portage lets me do that).

[qsmodo]

About the text editor discussion: I think one ought to be included even in a minimal installation, as it is now (no, ed doesn't count ). Heck, as psycho says, vi is in the POSIX standard.

However, vi is not for the uninitiated. Then nano is a good choice, but I remember back when I was still new to GNU Linux that the step saving files was confusing. You got to press two Ctrl-this Ctrl-that combinations. The mc editor is so much better in this aspect, yet never gets attention, probably because it requires installing mc in the first place.

I was way behind. Now I get it: qsmodo is looking at the official set names. There *is* a @selected set that I've somehow never noticed and that corresponds to the world file, so it would indeed make more sense for that file to be called selected. Having two different sets named "selected" and "world", and then having the "world" file list the packages in the "selected" set rather than the "world" set, is indeed somewhat bizarre from a newcomer's perspective. I'm so used to the world file's role in defining my @world set that I think of this relationship as obvious and intuitive, but it really isn't, in the context of the package set names listed on the wiki: I can see how, for someone trying to make sense of the terms on that page, it is quite a confusingly inconsistent use of the term "world".

Yes, that's exactly what was bugging me.

Oh well. My boxes still seem to be chugging along quite nicely, despite their @selected packages being listed in a file named world, and their @world packages including a whole lot more than the packages in that world file. I don't think they'll lose any sleep over it so I won't either...and I'm not going to get myself out of sync with the normal usage by redefining the sets locally, though it's nice to know we can do that. Obviously I didn't pay enough attention when package sets were introduced (I basically just ignored them, continuing to refer to world rather than @world, since portage lets me do that).

Yup, I totally agree there, no point in redefining sets now that the relationship between the sets and the world file is clearer.

[Genone]

I was way behind. Now I get it: qsmodo is looking at the official set names. There *is* a @selected set that I've somehow never noticed and that corresponds to the world file, so it would indeed make more sense for that file to be called selected. Having two different sets named "selected" and "world", and then having the "world" file list the packages in the "selected" set rather than the "world" set, is indeed somewhat bizarre from a newcomer's perspective.

Yeah, but as said, we (rather I) did actually redefine @world to only include the contents of the world file. That change was very disliked by users as it messed with their routines. So the new definition of @world was renamed to @selected, and @world redefined again to include @system and @selected. If the filename would have been changed in the same way there would have been similar resistance and/or confusion, plus actual breakage from uncovered migration paths (there is only so much you can do) and broken third-party tools. And in the end the filename should only be considered an implementation detail and not as an interface of any kind.
TL;DR: People don't like disruptive changes.