In order for the GNOME 3 masks to keep and/or improve their value, maintaining the software is what this is all about; given that it will break more and more over time, in various ways due to incompatibility and insecurity, who is going to maintain it?

I fiddled today a little bit with this stuff on my desktop. I use xfce4 on the stable and the regular desktop profile.

I did mask >=gtk+-3.0.0 and wanted to see what breaks. As a rule of thumb, all nearly all redhat stuff depends on > gtk+3 . I found out that two not really needed features depend at the xfce4 desktop on >gtk+3. libnotify and libcanberra. I dont need sound notification from libcanberry. I can live without libnotify.

So as a resume, i ended up with a very small mask:

>=x11-libs/gtk+-3.0.0
>=x11-libs/libwnck-3.0.0

and in make.conf under the USE="xxx" section ...

-gnome -gtk3 -gtk -libcanberra -libnotify

Maybe it helps someone to keep it away from the box.

An short emerge -p cinnamon, wants to pull in systemd ... i was shocked

An short emerge -p cinnamon, wants to pull in systemd ... i was shocked

It can satisfy multiple virtuals (udev, service-manager, ...) thus could get pulled in easily that way; even when it isn't listed first, USE flag inconsistencies can cause a different implementation to satisfy the virtual. A rule of thumb to avoid implementation switching is to keep the USE flags of the virtual and the package that you want to satisfy the virtual with consistent.

No-one wants to maintain such masks; that's why the slotting should have been carried out in line with standard practice, not some excuse for a reason that pushes everyone in the direction the Gnome3 developers want to go, no choices and no questions asked. Fine it hasn't, and we are where we are. That doesn't stop where we are being an awful lot worse than where we could have been.

If you don't like your actions being queried and sometimes criticised, don't work on a public distribution, expecting others to use your work. It goes with the turf, and it will never change, quite rightly afaic. If you want everyone to nurture you and value your every word, you need to grow up.

Similarly, nobody wants to maintain such slotting; that's why more manpower is needed, as I think that the GNOME team is not going to suddenly maintain double the amount of work. If you want Gentoo to become better than what it is, you're welcome to join and improve it; but querying and criticizing about it is not magically going to make a change in packaging or a change in the amount of work that can be dealt with occur, that's the reality that we live in.

Pfft, you just use a new slot and move the old ebuilds to the attic when you've had enough of them; meantime you haven't poisoned the well for people who come after you and might want to continue using them.

If Gentoo wants to improve, developers should stop being so defensive about their egos and get on with the job at hand in the most efficient manner, without making loads more work for users, just to push their half-baked agendas.

And please stop putting words in my mouth; I have repeatedly said it's too late to put it right, so I am not "magically expecting" anything to happen, beyond an improvement for next time somebody feels like poisoning the tree.

A new SLOT introduces a ton of file collisions and broken file location expectations including those of reverse dependencies; the efficient way to keep at least one working SLOT of GNOME is to not introduce SLOTs, as that goes without making loads more work for the limited manpower available. There is no reference to expectations in my previous comment; but rather a reference to manpower, that determines whether we reach the deadline.

Oh, thought you left this discussion steveL.
Let me leave you with http://devmanual.gentoo.org/general-concepts/slotting/ then. I have no idea how what you keep insisting on here are in line with standard practice, as they are in line with huge QA violations instead.
Also please stop spreading lies about my team, I thought you are better than that.
For anyone wanting to stick to GNOME2 era metaphors, we fortunately now have MATE available to please your desires. Unlike gnome2, it is actually maintained upstream, not dead for the past 3+ years _________________GNOME team lead; GStreamer; MIPS/ARM64

For anyone wanting to stick to GNOME2 era metaphors, we fortunately now have MATE available to please your desires. Unlike gnome2, it is actually maintained upstream, not dead for the past 3+ years

Pardon the mild off-topic intrusion, but does MATE have a login manager? I've been using gdm for years, but now have it masked <3.8 so I can stay with OpenRC. On a new install I just installed LXDM, but find that it does not obviously/readily support remote X operation.

From a login manager I need:
1 - Desktop agnostic - my wife uses xfce, I use a simple window manager.
2 - Remote X - I export DISPLAY all over the place on a regular basis, at the very least for weekly maintenance.
3 - autologin - For my wife, on her computer, a basic part of W.A.F.
4 - XDCMP support, sometimes really handy for work-from-home.

Today GDM gives me all of this, but as is noted in thiw masking discussion those days are numbered, so I need a replacement. I completely forgot about #2 because I thought it was so basic, so I overlooked it when I installed LXDM on one system. A little web searching suggests that it may not even be possible - it sounds like the configuration stuff in starting the X server may not be fully working. If MATE has a spinoff of GDM that would work for me._________________.sigs waste space and bandwidth

depontius, I use SLIM for a variety of reasons. To log in remotely try this:

1. On the target machine edit /etc/ssh/sshd_config, make sure X11Forwarding is set to yes , save and run /etc/init.d/sshd restart
2. In a window manager terminal on the other machine, run ssh -Y username@targetmachine mate-session i.e. 'ssh -Y tony@192.168.0.104 mate-session'

I think this will duplicate what XMing does. If your wife's computer uses Windows, then I KNOW Xming will log into Mate because I'm doing it right now. If this is the case, reply back and I will give you a step-by-step to downloading and configuring Xming.

Oh, thought you left this discussion steveL.
Let me leave you with http://devmanual.gentoo.org/general-concepts/slotting/ then. I have no idea how what you keep insisting on here are in line with standard practice, as they are in line with huge QA violations instead.
Also please stop spreading lies about my team, I thought you are better than that.

I haven't lied about anything: instead we've had the spectacle of several developers repeatedly lying about what I have said, and presenting that lie as something to argue with, instead of admitting that there is no way on Earth that anyone sane would put Gnome-2 and Gnome-3 in the same SLOT.

Instead we've been told they are in fact different packages, but good luck with that: if you have something specific beyond a page that doesn't back up anything you have said, please present it. You know the actual killer point you appear to believe is present on that page: be direct and present the argument, not some limpid claim to authority that isn't.

Way to go presenting Mate as "your team's" work, when it was worked on by users, and took quite a while to be picked up by "your team". Clearly you've changed in the last few years; that'll be the company you keep, imo. You're certainly much better at the propaganda game. Would that that was matched by technical clarity.

Then please provide resources to back up your claims.
You can make a working prototype of GNOME 2 working on a GNOME 3 system to prove your point.
Among other things, the amount of required work keeps you (and us) from doing that.

steveL wrote:

instead we've had the spectacle of several developers repeatedly lying about what I have said, and presenting that lie as something to argue with,

Given no resources to back up your claims, it is hard to make the claim that we lie;
you can present it as such, but it needs resources to back it up and have it reach a higher potential.

steveL wrote:

instead of admitting that there is no way on Earth that anyone sane would put Gnome-2 and Gnome-3 in the same SLOT.

They are in the same SLOT; so, we've managed to find that way on Earth, with the least amount of work.

steveL wrote:

Instead we've been told they are in fact different packages, but good luck with that: if you have something specific beyond a page that doesn't back up anything you have said, please present it. You know the actual killer point you appear to believe is present on that page: be direct and present the argument, not some limpid claim to authority that isn't.

Way to go presenting Mate as "your team's" work, when it was worked on by users, and took quite a while to be picked up by "your team". Clearly you've changed in the last few years; that'll be the company you keep, imo. You're certainly much better at the propaganda game. Would that that was matched by technical clarity.

Where was it said that they are different packages?
Where was it said that they are their team's work?

Oh great, even more work; as you can see, it isn't as simple as just setting the SLOT value.
And if you would change the above files, you'll also need to change the references to gnome-session in the reverse dependencies.

This is one of the simplest GNOME packages, thus other packages involve more work due to more dependencies and files;
doing this for all GNOME packages, needs a lot of work. That needs people to step up, prove it is possible in an overlay, add and maintain it.

The MATE desktop accomplishes this work, as we can run MATE inside GNOME 3;
but that certainly didn't come for free, as can be told from the commit history of their packages.

He has separate SLOTs that block eachother in mind, I believe. Like the tricks www-client/google-chrome was playing, until it was migrated to 3 separate packages._________________GNOME team lead; GStreamer; MIPS/ARM64

He has separate SLOTs that block eachother in mind, I believe. Like the tricks www-client/google-chrome was playing, until it was migrated to 3 separate packages.

Such tricks beat the purpose of SLOTs; because it then behaves like separate packages, where conflicts are then to be fixed up.

Blocks are hacks because they don't fix conflicts; they replace an error elsewhere, then you know about conflicts but refuse to fix them.
Liberal use of such blocks split up the Portage tree in groups of packages that cannot be installed together.

This boils down to whether categorization is welcome in the Portage tree; at the moment, the way commits happen is against
this categorization by changing file paths, introducing compatibility patches, dropping old / unmaintained / broken stuff and so on...

When one user wants to run nothing but GNOME 2 doesn't mean that other users don't want to run nothing but GNOME 2,
as a result of blocks those other users will be in a broken scenario; no, instead we're now in a working scenario
where you can run MATE 1.8 on top of GNOME 3.12 as well as run GTK+ 3 and GNOME stuff on top of MATE 1.8, awesome.

Gentoo and other efforts allow you to easily mix stuff like that, we shouldn't take away that ability by liberally using hackish blocks;
that's why we spend time on forks that maintain compatibility, instead of resurrecting an incompatible GNOME 2 from its grave.

Well I got careless during today's upgrades and lost the trusty old gdm-2.20 I've managed to keep going since the start of this tread.

The good news is the mate-overlay has mdm-1.4.11 which works fine (I never was able to get the ebuilds in bugzilla to emerge)

That's good to hear. Last I heard a few months ago, mdm wasn't doing so hot. If you decide you need it, I've got all of the bits'n'pieces of gdm-2.20 saved._________________.sigs waste space and bandwidth