Behavior of package sets regarding "world"

skogs · n00b Joined: 03 Mar 2006 Posts: 28

It matters not to me. I'm just excited by Genone's shadow ship.

bluesea · n00b Joined: 10 May 2004 Posts: 27

A question: What happens when two sets contain common atoms? Will deleting one set "break" the second set? Will atoms need "referenced by" counts to avoid this?

Just thoughts. I'm not sure about how to vote right now, but whatever the result, I hope we can customize the behavior to our needs.
_________________
erutangiS

Genone · Posted: Tue Mar 18, 2008 8:05 pm Post subject: Re: set intersections

bluesea · n00b Joined: 10 May 2004 Posts: 27

Genone · Posted: Tue Mar 18, 2008 9:39 pm Post subject: Re: set intersections

Joe_Sextus · n00b Joined: 28 Feb 2006 Posts: 45

I think it should be setup so that system + usersets + air = world. This way emerge -u air updates everything not in a set, but emerge -u world still updates everything.

steveL · Posted: Thu Mar 20, 2008 8:28 am Post subject:

dol-sen · Posted: Sun Mar 23, 2008 7:21 am Post subject:

I have voted no, with persistent opt-in.

Sorry, It took so long for me to find this thread. Thank you GMN.

In porthole, (I know the new release is long, long overdue) It's upgrades list separation and sets support (regardless of the installed portage's feature availability) separates packages by the following code excerpt:

red-wolf76 · Posted: Thu Apr 03, 2008 5:04 pm Post subject:

I voted "yes with persistent opt-out", but I see a number of problems that make me want to change my vote on second thought. Not being a programmer, I don't have any clever ideas about solving them, but maybe someone else does.

Consider the following situation:
1.) world contains packageA (because you emerged it at some point) as well as @setA, which also contains packageA.
2.) if portage just blindly iterates through the world file whenever emerge -uDN world is called, this would mean that we would emerge packageA twice. Once for the entry in world proper, once for the @setA entry in world because it is contained in @setA's list.

It gets worse, when you get subsets containing redundancies or multiple sets contain the same package, as was mentioned somewhere further up.

It would probably be best to keep world in a clean format, while still being able to use sets. Either you involve an auto-cleaning mechanism that eliminates "top-level entries" for packages contained in one (or more) set(s) from the world file, or portage will need to generate some sort of "build list" everytime it is called and eliminate duplicates or "illegal removes" from that list on the fly.

The latter would have the charm of keeping sets that contain packageA intact when you remove another set that also contains packageA. Also, emerge -C packageA would need to have precedence over set dependencies, even if the next emerge -uD world would restore the package, since some packages don't like updating while installed for some reason.

Does any of this make sense?
_________________
0mFg, G3nt00 r0X0r$ T3h B1g!1111

Use sane CFLAGS! If for no other reason, do it for the lulz!

Genone · Posted: Thu Apr 03, 2008 5:08 pm Post subject:

red-wolf76 · Posted: Thu Apr 03, 2008 5:11 pm Post subject:

Ah, then it already does some of the stuff that is suggested?

Actually, aren't sets and metapackages somewhat related? I mean, it's obvious they're not the same thing, but don't they serve sort of the same purpose?
_________________
0mFg, G3nt00 r0X0r$ T3h B1g!1111

Use sane CFLAGS! If for no other reason, do it for the lulz!

Genone · Posted: Thu Apr 03, 2008 6:40 pm Post subject:

lefsha

ferringb · Retired Dev Joined: 03 Apr 2003 Posts: 357

Shifting the posting around a bit...

nixnut

red-wolf76 · Posted: Sun Apr 13, 2008 12:44 pm Post subject:

Whoa, some serious calming down may be required here, I think.

First of all, I'm not a developer. I'm not sure I'm all that knowledgeable as a user either. I do have an opinion of what I want portage to do for me, even if I am completely happy to leave the designers to actually make the decisions about whether this is at all sensible or how to go about it, if it is.

In an ideal world (pun intended to some degree), everyone would be writing ebuilds in a way that would allow portage to start calculating what to emerge from a minimum of "required" packages set down (by the distro, the profile, the user). In an ideal world, dependencies wouldn't show up anywhere, save in those cases where unmasking is required and stuff has to go in /etc/portage/package.keywords or even (if you're feeling lucky!) /etc/portage.unmask and would always be generated on the fly according to the requirements of your USE-flags and the few packages that you positively want to have installed.

As portage adds stuff to world after emerging it (after all, you told it that you wanted it installed. Period.) it seems likely that user error will cause world to become cluttered, if foo is already part of an installation because it is a dependency of bar and now becomes a top-level candidate as well because the user forgot to put --oneshot into the command. Sure, one may think of checking the dependency tree before letting portage add foo to world, but the question of how much thinking one wishes to free the user? Certainly, trying it the other way around (with --oneshot being the standard setting) should produce most hilarious results for packages that are not dependencies of others, should a user decide to try this amazing emerge --decplean he's been reading so much about in the fora.

The problem with sets - as I understood them - lies in the question of priorities when merging and unmerging them, or their individual packages. The set "foo" may contain package "bar", but what happens if "bar" is also part of world next to foo, or what would happen to bar if a second set containing a different non-slotted version gets installed...

But I'll gladly leave that to the actual boffins in charge of development. I'm actually quite happy with portage and the power it gives the user. Sure, there are a few caveats, but that holds for almost every tool out there, I guess.
_________________
0mFg, G3nt00 r0X0r$ T3h B1g!1111

Use sane CFLAGS! If for no other reason, do it for the lulz!

Akkara · Posted: Mon Apr 14, 2008 8:01 am Post subject:

I noticed that many of the reasons given in support of the various choices can be summarized as wishing for a particular set-operator over the default and user-defined sets.

Which suggests an idea: perhaps implementing set-operators directly.

So the person wanting to update everything except for their webapps, could perhaps emerge -u "world & !webapps" (to pick a C-like syntax for discussion; the actual syntax would most likely be different).

In fact, set definition itself could be done with such operators.

Then the "world" set can continue to be the set of all things explicitly emerged by the user (including sets), since exclusions would easily be handled by the operators.

Sets themselves would probably have to be dynamically evaluated. E.g., edefine nokernel = "world & !gentoo-sources" should expand the definition each time, not take the snapshot of world as it exists at the time this command is entered.

And there could even be some officially-published and updated sets that come with emerge --sync. For example, a set of all security updates, so that emerge -u security would update all security-related issues (and their deps), and nothing else.

But this is all probably well beyond the scope of the implementation that's in plan behind the scenes. Just ignore it if so; I don't intend to make impossible suggestions, only noticing the similarities between this and operators.

PS: I'd also like to take this opportunity for a quick thanks of appreciation for all who work on the various aspects of Gentoo!

Genone · Posted: Mon Apr 14, 2008 11:17 am Post subject:

dagurasu · n00b Joined: 29 Apr 2005 Posts: 74

steveL · Posted: Fri Apr 18, 2008 8:26 pm Post subject:

Genone · Posted: Mon May 12, 2008 4:54 pm Post subject:

Ok, in 2.2_pre7 there will be a new option 'world-candidate' in sets.conf, and most default sets will have it set to 'False' (except for 'system' and file-based sets in /etc/portage/sets/), meaning that they will not be added to the 'world' set. Users can override it in /etc/portage/sets.conf, e.g. if you don't want 'system' to be recorded in 'world' you'd add the following: