When I first started using Gentoo maybe 4 years ago I was very impressed with a number of things that I haven't seen in other distros then or since.

These were, for me:

1) a new level of customization we hadn't seen before
2) Documentation. Actually understanding the system at a greater level by doing things in a less Windows/automagic way, well documented, and thus better learning hands-on
3) the widest availability of packages I had ever seen.

I still think Gentoo is still no.1 for 1 & 2 but now I visit Gentoo I'm finding it doesn't match the availability of packages for Ubuntu by a long way.

There are workarounds for this such as overlays. But the problem here is that this quickly gets complicated and it fragments the userbase.

At some point I heard there was a decision to remove software that is no longer being updated. Is this true? I was devastated when I first heard this. I felt I had lost Gentoo somehow.

Where can I read more about this and get some background info on how people reacting when the decision was first made while I was away experimenting with Ubuntu. What keyword do I search for on http://planet.gentoo.org/ ?

On paper the decision makes sense - to be minimal as a base so then the overlays can be built on top...
I'm just not sure this is the best decision when community and human nature is taken into account?_________________Sabayon is basically Gentoo with an additional binary package manager system as well - but you can't use USE flags as that breaks compatibility - watch out

MANY of the overlays you can see listed with layman are not very good. Alot of those ebuilds suck. So there is something to be said about a centralized system of management. But then I guess it comes down to maintainability. The system as it currently is seems to be much more stable. I've had far less build time problems than I've had before so I suppose the decision worked out for the best._________________MB: Biostar TForce 6100 AM2 @ 250x10
CPU: AMD Athlon 64 3800+ X2 @ 2500mhz
MEM: G. Skill DDR2-800 2GB @ DDR2-1000
GPU: nVidia GeForce 7600 GT
OS: Gentoo Linux 2006.1

I do not agree. It is OK to mask packages which are actually not maintained and thus might have security issues: This way the user needing this packages knows that he has to be careful and perhaps fix some issues. However, I think it is a horrible decision to remove those packages from the tree.

A recent example is the upcoming removal of the package app-portage/epm: This package has absolutely no issues. It is only removed because there were some unanswered feature requests (submitted as bugs on b.g.o.) how to make it behave more similar to rpm. This shows only that this package is no longer maintained. So masking might be appropriate - the user should know that he might have problems with the package and that he should not expect that they will be solved - but removing it from the tree just for this reason is very bad IMHO.

At some point I heard there was a decision to remove software that is no longer being updated. Is this true? I was devastated when I first heard this. I felt I had lost Gentoo somehow.

Where can I read more about this and get some background info on how people reacting when the decision was first made while I was away experimenting with Ubuntu. What keyword do I search for on http://planet.gentoo.org/ ?

Did you hear this from me? I should clarify I don't know how widespread the practice of dropping old, undeveloped packages from the Portage tree is or when it started.

I first noticed it when the Frodo Commodore 64 emulator was ported to Android. It has an average rating of 4.3 out of 5 based on >1000 reviews in the Android play store. https://play.google.com/store/apps/details?id=org.ab.c64&hl=en. A lot of people were recommending the program but I noticed that it had been dropped from the Portage tree. AFAIK it wasn't moved to any of the community overlays. I had to search around online for an old ebuild and add that to a local Portage overlay. And what do you know, after 1 small edit to the ebuild to include a patch it compiles and runs perfectly.

mv wrote:

I do not agree. It is OK to mask packages which are actually not maintained and thus might have security issues: This way the user needing this packages knows that he has to be careful and perhaps fix some issues. However, I think it is a horrible decision to remove those packages from the tree.

I think it only applies to orphaned packages that haven't had any upstream development in years. It's as much about security as it is countering the perception that the Portage tree is "rotting".

I think it only applies to orphaned packages that haven't had any upstream development in years.

So what? If e.g. a developer of a package has decayed and nobody else took maintainership, it means it must be removed from Gentoo even if it compiles and works perfectly well?

Quote:

It's as much about security

Then mask it, and everybody knows he has to be aware about possible problems.

Quote:

the perception that the Portage tree is "rotting".

Nobody except perhaps some bureaucratic gentoo developers have such a perception: Having the possibility to use aged software, even if seldom used, is just nice and not any sort of disadvantage.

The problem is that once removed from the tree, a package is practically lost for all gentoo users: Even if the rebuild and files/ can still be found in CVS (or in future perhaps in git), the sources (or maybe larger patches distributed only over the mirrors) might long be inaccessible, especially if the original maintainer has decayed or has left programming forever.

Maybe I used the wrong adjective, sorry for my English. What I meant is that for a developer from treecleaners a "rotten" package may appear bad, but in this position he has a very limited point of view. I never heard somebody "from the outside" (user or even user of a different distribution) complain that the gentoo tree is too big. If there are complains then only that it is too small or that a certain package is not available. IMHO one should overcome the viewpoint that "old and unmaintained" = "rotten".

Quote:

Its my experience that only broken packages are dropped.

epm is such an example; in the same post on the developer list there were a dozen other well-working packages mentioned which will probably be removed. ufed just hardly was removed from this list.
Other recent example of unnecessary removals (they compile perfectly well even with gcc-4.7.1): scilab, ispell (and its dictionaries); somewhat older example: xmame (it still works here). Of course the actual list would be way longer; these were just the packages which I kept in my overlay (and the tarballs in separate places) to save them. Sure, these examples might have security issues, but since they are not SUID/SGID and are not filled with untrusted data: what bad can happen?

I think this is good for user-devs and people customising Gentoo with USE flags who I think experienced way more bugs than me. I am different from them because I tended to use Gentoo like a user, keeping everything as stock in the most part and then enjoying that wide choice of packages and customisation only from time-to-time. I rarely remember having any bugs 4 years ago but that differs from what other people have been saying.

Anyone coming to Gentoo these days for package availability purpose is quickly going to give up on Gentoo - quite a tradeoff. Ubuntu is now easier from that viewpoint. Even RedHat can sometimes offer a package quicker.

What would be a wide range of overlays to install that would bring back the old days? ... but not so much to introduce bugs? This would be especially useful for forks such as Sabayon users who are using portage for extended package availability (only?) anyway and as long as those packages are not wide dependency providing - it shouldn't effect them too much?

Ideally, an overlay which provides all packages that provides no dependencies and uses few shouldn't effect system stability...
but I don't think there is an overlay like that - Sunrise is for new packages. I am interested in mothball type packages that haven't been updated in years because the guy who wrote was happy with it and now has better things to do. Standalone packages like steghide for example. Those kind of packages used to be really useful in Gentoo.

I think Pentoo proves the point. Years ago this fork wasn't even available - all the packages like that were in portage. But now we have the separate project and slowly those packages are being imported to the mainline. It's good to have better testing this way, but not for everyone.

edit:

Or perhaps script:
- add every overlay possible
- search for package
- if available, inspect the dependencies manually and carefully install it
- remove the overlays previously added_________________Sabayon is basically Gentoo with an additional binary package manager system as well - but you can't use USE flags as that breaks compatibility - watch out

I thought I'd save some time by installing a gimp plugin but it seems that manually is the only way without an overlay.

This seems extreme. To have 3 results for the search term "upload"?!_________________Sabayon is basically Gentoo with an additional binary package manager system as well - but you can't use USE flags as that breaks compatibility - watch out

Honestly, for the non-system standalone packages, I am finding now old-style ./configure, make into /usr/local easier

This has so many disadvantages that I would not even consider doing so (orphan files and other difficulties to uninstall, possibly even a completely broken system if the makefile is buggy, no automatic handling when libraries are updated [revdep-rebuild], no overview which file belongs to which package, ...)

Honestly, for the non-system standalone packages, I am finding now old-style ./configure, make into /usr/local easier

This has so many disadvantages that I would not even consider doing so (orphan files and other difficulties to uninstall, possibly even a completely broken system if the makefile is buggy, no automatic handling when libraries are updated [revdep-rebuild], no overview which file belongs to which package, ...)

Well, I would not install this way system packages (to break a system), but since I have several custom scientific packages installed in /usr/local anywaye ,
few more makes little difference.

More seriously, although ./configure & make may have high maintenance costs (I'd reiterate - not so much for standalone package, which you can just delete with rm if needed), it has much lower deployment costs than dealing with overlays as discussed above.

Well the thing is that I have heard (want to see the official statement on this?) that it's not a case of unstable packages being removed but rather, unmaintained packages. A great many programmers are known to make something, get it to stable and then move on in their lives. While that might be a problem for network facing services it would be nice to have them available as an overlay, "legacy" or something like that._________________Sabayon is basically Gentoo with an additional binary package manager system as well - but you can't use USE flags as that breaks compatibility - watch out