Masking Gnome 3

[Anon-E-moose]

Edit: Anyway, y'all have fun trying to get everyone else to accept only your views. I wish you well in that endeavor.

[TomWij]

Every time a new library release comes out has a risk of generating dependency hell with blockers.

It goes further, the blockers are for cases we can account for because they are obvious and causes a quite visible listing in the configure script or a failure in every build; however, those that we don't account for would result in compile time or even run-time failures.

Is it not weird that MATE is taking so long to be integrated and stabilized in the main portage tree despite all the "work" has already been done? Or is there "work" not being accounted for?

Until a few days ago developers were running other desktop environments; but it will be brought to the Portage tree now as it gets used, it will go at a fast rate and is just waiting half a week for feedback to decide which category it will put it in. After that it will enter the Portage tree at a rate of a few packages a day; at that rate, it is expected to be reviewed, corrected and in the Portage tree in under 2 weeks.

[steveL]

Is it not weird that MATE is taking so long to be integrated and stabilized in the main portage tree despite all the "work" has already been done? Or is there "work" not being accounted for?

Not really: it takes time to import stuff from an overlay, since it has to be reviewed and tested before someone will put their name to it. And it still has to go through normal stabilisation and arch-testing after that.

[SamuliSuominen]

Every time a new library release comes out has a risk of generating dependency hell with blockers.

It goes further, the blockers are for cases we can account for because they are obvious and causes a quite visible listing in the configure script or a failure in every build; however, those that we don't account for would result in compile time or even run-time failures.

Is it not weird that MATE is taking so long to be integrated and stabilized in the main portage tree despite all the "work" has already been done? Or is there "work" not being accounted for?

Until a few days ago developers were running other desktop environments; but it will be brought to the Portage tree now as it gets used, it will go at a fast rate and is just waiting half a week for feedback to decide which category it will put it in. After that it will enter the Portage tree at a rate of a few packages a day; at that rate, it is expected to be reviewed, corrected and in the Portage tree in under 2 weeks.

Thanks TomWij for taking on the task! Let me know if I can help, again, to a extent, I'm not really willing to flip away from Xfce.

[steveL]

I don't understand why people don't understand there are big problems in making sure every file is no longer disturbed. Perhaps the only way to make it clear to everyone is to make sure for Gnome to make one last statically linked library for Gnome2, else conflicts will keep on occurring as time goes on.

I'm not sure what you're getting at with this. There's no need to worry about "every file being disturbed" if you make the SLOTs conflict: the package manager takes care of them. And then you wouldn't have all the difficulties with trying to mask specific versions; in time the old ebuilds either die off or remain in an overlay.

And this thread is NOT helpful. Every time a new library release comes out has a risk of generating dependency hell with blockers. Because there was no mask file that works for everyone (every single one posted in this thread does NOT work for me, along with the effort made to devise my own) I had to grudgingly migrate to other DE that was supported. Believe me, if there was a way to stay at gnome2 or convert to MATE I would have gone this route.

Yes that's the avenue that was deliberately closed off by making the Gnome-3 ebuilds have a 2.0 SLOT, contrary to all standard practice. If anything there was a case for making it a completely different package, let alone SLOT, since it does not provide anything like the same setup, and in fact represents a whole new application environment. Closing off that route appears to be one of the major objectives: technical soundness and avoidance of file collisions certainly were not; as noted the latter is much better served by a simple SLOT conflict in the ebuilds or eclasses, applicable to the old not the new.

If there is a mask that works for everything and I can keep other things updated without breaking gnome2 I ask you to do that work and send it to this thread. I still have two or so machines that I have not converted and are ready for your masks.

Thinking about it the easiest mechanism would be automated patching to make the Gnome3 ebuilds use a correct SLOT value in an overlay, eg local. Not sure if anyone's really interested in that, particularly wrt other ebuilds that depend on them. Though I guess those are going to be pretty high-up in the stack, if they depend on gnome3/systemd, and you're not talking about patching anything upstream, as one might have to with semantic-craptop on KDE.

[TomWij]

I don't understand why people don't understand there are big problems in making sure every file is no longer disturbed. Perhaps the only way to make it clear to everyone is to make sure for Gnome to make one last statically linked library for Gnome2, else conflicts will keep on occurring as time goes on.

I'm not sure what you're getting at with this. There's no need to worry about "every file being disturbed" if you make the SLOTs conflict: the package manager takes care of them. And then you wouldn't have all the difficulties with trying to mask specific versions; in time the old ebuilds either die off or remain in an overlay.

The package manager does no such thing, it does what the ebuild specifies it to do in src_install (and other relevant phase functions); if you introduce a new SLOT, the files will be in the exact same place as before with that new SLOT. And thus, you need to move files into the ${SLOT} directories in src_install; but it goes further than that, you need to make sure that the reverse dependencies that call those files can still find them which means you need to patch them.

[steveL]

The package manager does no such thing, it does what the ebuild specifies it to do in src_install (and other relevant phase functions); if you introduce a new SLOT, the files will be in the exact same place as before with that new SLOT. And thus, you need to move files into the ${SLOT} directories in src_install; but it goes further than that, you need to make sure that the reverse dependencies that call those files can still find them which means you need to patch them.

You missed the bit about "if you make the SLOTs conflict."

[Leio]

Yes that's the avenue that was deliberately closed off by making the Gnome-3 ebuilds have a 2.0 SLOT, contrary to all standard practice.

[citation needed]

[EvaSDK]

What steveL is saying simply isn't true. It's not the Gentoo packagers that have "poisoned" some packages but rather the original upstream of them, such as dev-libs/glib, have changed and since Gnome 2.x doesn't have a upstream anymore, they haven't been patched to be compatible with the newer libraries.

..It was GNOME upstream who decided to call binaries/libraries/headers and so forth the same, like eg. gnome-terminal is still gnome-terminal and not gnome3-terminal so that
SLOTting was impossible. Those that were possible to SLOT, have been SLOTed.

I'm calling "bullshit" on this. SLOT conflicts are no excuse for deliberately keeping the 2.0 SLOT for 3.0 ebuilds. The conflicts go in the old ebuilds, as you move to the next generation.

The point, as you well know, is that the GNOME herd could have simply moved to SLOT 3.0 for the new ebuilds, just like KDE or any other setup. The only reason not to do so is to force people to upgrade, and to remove the the option of masking by SLOT.

No, this was not possible for every packages. But since you are so aware of what it takes to do ebuild maintenance, I am waiting for your quizzes. I am not kidding.

[TomWij]

The package manager does no such thing, it does what the ebuild specifies it to do in src_install (and other relevant phase functions); if you introduce a new SLOT, the files will be in the exact same place as before with that new SLOT. And thus, you need to move files into the ${SLOT} directories in src_install; but it goes further than that, you need to make sure that the reverse dependencies that call those files can still find them which means you need to patch them.

You missed the bit about "if you make the SLOTs conflict."

That beats the purpose of adding SLOTs as they lose their advantage; you might just as well add blockers against the other / newer versions of the package, which reaches a similar effect as using a set though requires more work and more mess in the ebuild to achieve. Set support in the Portage tree would be a solution here; however, this is just one part of the full picture to keep GNOME 2 in place. Others involving breakage were mentioned earlier in this thread. Even if you still would use this slotting and blocking approach, this would have its consequences on the non-GNOME reverse dependencies which then also have to adapt for that introduction; in reality, that will result in a lot of slot conflicts and/or blockers and require a lot more work from other Gentoo developers and users too. As a side effect, it will slow down Portage...

[steveL]

SLOT conflicts are no excuse for deliberately keeping the 2.0 SLOT for 3.0 ebuilds. The conflicts go in the old ebuilds, as you move to the next generation.

The point, as you well know, is that the GNOME herd could have simply moved to SLOT 3.0 for the new ebuilds, just like KDE or any other setup. The only reason not to do so is to force people to upgrade, and to remove the the option of masking by SLOT.

No, this was not possible for every packages. But since you are so aware of what it takes to do ebuild maintenance, I am waiting for your quizzes. I am not kidding.

Well, since you say you are not kidding I will respond in kind. Please elucidate why it was impossible. There are plenty of conflicts in the tree already; they are nothing new.

I keep reading "it was mentioned earlier in the thread" (as well as inane nonsense) but I cannot find any such reasoning whatsoever. Just repetition of the file-collision mantra, as if that were any sort of justification. It's not even the same package, according to the reasoning given, let alone the same slot. It just happens to use the same filenames at install, apparently for the same broken reasoning upstream (let's force them to use what we tell them.) Call me old-fashioned, but I expect a distro to shield me from upstream stupidity, not use it as an excuse for what I must still consider flawed or agenda-driven reasoning (pick one.)

As for ebuild maintenance, I am not particularly interested in it. Compared to real bash scripting, it's pretty limited, which is fair enough: it's domain-specific. But I'm not really a scripter: I just wanted to learn bash, and my [topic=546828]learning exercise[/topic] turned into an ongoing project, purely for convenience. I've been asked to contribute stuff before, and I have. I've also been treated pretty shabbily, by various factions of Gentoo developers, and while I'm happy to contribute to the community, I have much greater reservations about being associated with the developer-base, as a collective. Since collectively I find them quite embarrassing. I am not kidding, either.

No doubt someone will want to fling poo at me again; but I thought I'd respond to you in all seriousness, taking your words at face-value and in good faith.

[EvaSDK]

SLOT conflicts are no excuse for deliberately keeping the 2.0 SLOT for 3.0 ebuilds. The conflicts go in the old ebuilds, as you move to the next generation.

The point, as you well know, is that the GNOME herd could have simply moved to SLOT 3.0 for the new ebuilds, just like KDE or any other setup. The only reason not to do so is to force people to upgrade, and to remove the the option of masking by SLOT.

No, this was not possible for every packages. But since you are so aware of what it takes to do ebuild maintenance, I am waiting for your quizzes. I am not kidding.

Well, since you say you are not kidding I will respond in kind. Please elucidate why it was impossible. There are plenty of conflicts in the tree already; they are nothing new.

[...]

but I thought I'd respond to you in all seriousness, taking your words at face-value and in good faith.

My offer is to review your quizzes so you can eventually become a Gentoo dev and fix shit out.
Hint: most of the answers to your questions are in the devmanual and filling the quizzes will lead you to find the relevant points that have been brought up by devs in this thread already, not by empiric knowledge, but actual formally written sources.

[SamuliSuominen]

My offer is to review your quizzes so you can eventually become a Gentoo dev and fix shit out.

+1 +1 +1

[steveL]

My offer is to review your quizzes so you can eventually become a Gentoo dev and fix shit out.

OK: I appreciate that and I'll take a look at them.

Hint: most of the answers to your questions are in the devmanual and filling the quizzes will lead you to find the relevant points that have been brought up by devs in this thread already, not by empiric knowledge, but actual formally written sources.

Hmm I think you are referring to the subslot discussion in the SLOTs section. Frankly I agree with mcreesh on this: that should be done with correct slotting, following the soname. Either way you need to track it, so why not just reflect it directly? Regardless, the fact that those libs should not be installed in parallel, so they use the same SLOT, is no justification. They are in fact the same lib with ABI changes: gnome3 is nothing like gnome2. The reason for the subslotting is in fact to keep the main SLOT following the upstream version (though 1.5 would work equally well as 1/5, if not better.) That example argues more for different SLOTs between gnome2 and gnome3 (since one might think it a good idea to subslot 1.x and 1.y, but you'd never put 1.x and 2.y in the same SLOT.)

Slotting is not only about parallel installs: it's much more about software versioning. While parallel installs explain why SLOTs are useful, there's nothing wrong with SLOT conflicts.

When you said it wouldn't work for all packages, I took that to mean it was suitable for some, but not others because of a particular situation with those packages (apart from "gnome3 uses the same filenames as gnome2 therefore it must use the same SLOT.")

If you are referring to something else, please just link it directly. While I understand expecting people to read documentation, the devmanual has always been pretty light on detail, ime. In forum or email discussion it's usually better just to point out the source, so people can go and look at it, instead of batting messages back and forth. Personally I do the same on IRC. Though there's nothing wrong with expecting people to know where the devmanual is, if specific points are at hand, just link to the authoritative written source you have in mind.

[steveL]

you might just as well add blockers against the other / newer versions of the package, which reaches a similar effect as using a set though requires more work and more mess in the ebuild to achieve.

That's what was forced on every single user, instead of simply being able to mask by SLOT, and additionally Gentoo lost its chance to do a decent systemd profile, afaic. Which does fit with the usual agenda-pushing of systemd fanbois everywhere, and feeds the perception that a similar putsch is in effect in Gentoo. After all it's not hard to influence things when you can pay people to lobby on your behalf, and fashion is probably the worst reason to do anything in computing.

Set support in the Portage tree would be a solution here; however, this is just one part of the full picture to keep GNOME 2 in place. Others involving breakage were mentioned earlier in this thread.

No, again, all that's ever been mentioned is file-collisions. Please tell us another example of breakage that has been raised herein (I'm perfectly willing to accept I'm senile, but I am not searching this thread for a fourth time, so from here on in, I'm not doing the legwork to prove your conclusions. DIY.)

Even if you still would use this slotting and blocking approach, this would have its consequences on the non-GNOME reverse dependencies which then also have to adapt for that introduction

What? If it had been brought in with slot 3 (or 3.0) then that would never have been an issue, and you know it. As it is you have ebuild which specify dependencies in exactly the messy way you outline above, since there is no correct slotting.

in reality, that will result in a lot of slot conflicts and/or blockers and require a lot more work from other Gentoo developers and users too. As a side effect, it will slow down Portage...

More crap: correct slotting would be quicker for the manager, since the SLOT is pretty fundamental and usually simple metadata. As is you instead have ranged dependencies, which I promise you are a lot more work.

Sometimes I think you type too fast, and review too little.

[TomWij]

you might just as well add blockers against the other / newer versions of the package, which reaches a similar effect as using a set though requires more work and more mess in the ebuild to achieve.

That's what was forced on every single user, instead of simply being able to mask by SLOT, and additionally Gentoo lost its chance to do a decent systemd profile, afaic.

Adding the blockers in the package or in a set makes that masking obsolete, as users can just emerge the entire group of versions due to the blockers or set being in place.

Set support in the Portage tree would be a solution here; however, this is just one part of the full picture to keep GNOME 2 in place. Others involving breakage were mentioned earlier in this thread.

No, again, all that's ever been mentioned is file-collisions. Please tell us another example of breakage that has been raised herein (I'm perfectly willing to accept I'm senile, but I am not searching this thread for a fourth time, so from here on in, I'm not doing the legwork to prove your conclusions. DIY.)

Dependencies moving forward while GNOME 2 stays in place is a recipe for problems; for details, read the thread for the legwork proving the conclusion.

Alternatively, there is an exercise that demonstrates it: Revive GNOME 1 from the past.

Even if you still would use this slotting and blocking approach, this would have its consequences on the non-GNOME reverse dependencies which then also have to adapt for that introduction

What? If it had been brought in with slot 3 (or 3.0) then that would never have been an issue, and you know it. As it is you have ebuild which specify dependencies in exactly the messy way you outline above, since there is no correct slotting.

It will, as you'll break the reverse dependencies; go ahead and try it as an exercise and you'll see that the output of running `repoman full` in the root of the Portage tree will change.

That messy way, as well as the more appropriate set feature, are both examples of what you are using slotting for.

in reality, that will result in a lot of slot conflicts and/or blockers and require a lot more work from other Gentoo developers and users too. As a side effect, it will slow down Portage...

More crap: correct slotting would be quicker for the manager, since the SLOT is pretty fundamental and usually simple metadata. As is you instead have ranged dependencies, which I promise you are a lot more work.

Slotting introduces more possibilities, thus as a result more time is needed to enumerate those possibilities; which slows Portage down.

On the other hand, messy ranged dependencies as well as sets limit down on the possibilities; which speeds Portage up.

A similar thing can be seen with maintainers, as you can see as a consequence of the Portage tree `repoman full` difference exercise given above; besides keeping the packages themselves working.

[steveL]

FTR: I am bowing out, not because Tom is right, but because I don't want to continue arguing with such nonsense; you just end up chasing your tail along with the mutt. So if you're reading this, and think "he must have some answers and that's why the other guy shut up" you are incorrect. (It often appears like that on the dev ML too.) If you wish to discuss the matter more, try #gentoo-dev-help on IRC: chat.freenode.net, or the Portage and Programming forum.

Oh I was incorrect too, with "1.5 would work equally well as 1/5, if not better." It wouldn't without a SLOT conflict, so I can see why subslots appeal. They still have absolutely no bearing on this though, afaic.

[TomWij]

That is only so when the central point is this part of the discussion is refuted with documentation, policy and a proof of concept to give weight to that refutation; rather than this central point being claimed as nonsense. Even if it would be either, there are much more central points that show how GNOME 2 needs a lot of manpower to keep it working; some of which are mentioned throughout this thread, the rest is left as an exercise for those who take on the task to make a proof of concept that demonstrates how GNOME 2 can be kept working given a lack of manpower. MATE demonstrates the need for a lot of manpower argument; looking into it and its overlay, it has a rather large team (~20 people) of manpower behind it that makes it possible to keep GNOME 2 alive and kicking.

[steveL]

lalala

..has about the same semantic content, afaic. Out.

[TomWij]

If it does, then it means you agree with me. Thanks.

[Leio]

Gentoo is not in the business of maintaining obsolete 3.5 year old upstream unmaintained software. End of story indeed.

[katfish]

I noticed that the networkmanager doesn't depend on gnome.

So you do not need the following masks.

#>=net-misc/networkmanager-0.8.99
#>=net-misc/networkmanager-pptp-0.8.99
#>=net-misc/networkmanager-openconnect-0.8.99
#>=net-misc/networkmanager-openvpn-0.8.99
#>=net-misc/networkmanager-openswan-0.8.99
#>=net-misc/networkmanager-vpnc-0.8.99

Only the applet needs masking.

>gnome-extra/nm-applet-0.9.6.4

[heheman3000]

This thread was a lot of help to me. I believe I have successfully masked Gnome 3 and upgraded to Gnome 2.32.1.

This is for a box that I only access remotely using nxclient. (It's running net-misc/nxserver-freenx.)

Later I will consider migrating to mate or cinnamon.

Thanks, your package.mask still works after Gnome 3.10 is out. As you mentioned, I am only doing this because I have some servers that are accessed by NX, which completely breaks under GNOME 3 - and installing MATE right now is not only a pain in the butt but also doesn't work with the default NX login.

[TomWij]

In which way does that not work? Feel free to file a bug at https://bugs.gentoo.org such that that can be looked into.

[steveL]

Gentoo is not in the business of maintaining obsolete 3.5 year old upstream unmaintained software. End of story indeed.

That's not what the discussion was about and you know it, or should have if you bothered to read any of it.

So, thanks for the macho posturing and all, but it was completely misplaced. Honestly I thought you were better than that, leio.