On 07/08/2016 11:51 AM, Michał Górny wrote:
On Fri, 8 Jul 2016 18:33:35 +0300
Andrew Savchenko <birc...@gentoo.org> wrote:
On Fri, 8 Jul 2016 10:11:45 -0500 William Hubbs wrote:
I'm starting a new thread so this will be a completely separate
discussion.
On Fri, Jul 08, 2016 at 05:56:04PM +0300, Andrew Savchenko wrote:
On Fri, 8 Jul 2016 10:42:14 -0400 Rich Freeman wrote:
On Fri, Jul 8, 2016 at 10:30 AM, Anthony G. Basile <bluen...@gentoo.org> wrote:
Also there's some debate in IRC about whether or not these packages
should be lastrited or dropped to maintainer-needed. These forks are
not in good shape upstream, so I think it makes better sense to
p.mask/lastrite and then move them to the graveyard overlay when I
remove them from the tree in 30 days.
IMO the criteria should be whether they work or not. Not whether
upstream is more or less active.
If they're blockers on other work, by all means cull them. However,
if the biggest problem with them is that they're using a few inodes in
the repo, then they should probably stay.
+1
Best regards,
Andrew Savchenko
There is also an overlay for packages that are removed from the official
tree [1], and imo that is where old software should go if it doesn't
have an active maintainer.
I don't know why we haven't been using this, but using it more than we
have makes a lot of sense.
When software is in the main tree, it is a subject of tree-wide
changes like GLEP 67 update, package moves and so on. In a
separated overlay it will be completely abandoned and it may create
inter-overlay dependencies issues (e.g. when A is an old
package from the tree and package B from some overlay depends on A,
so if A will move to graveyard, B will be broken).
And that is the exact problem. As long as it's in Gentoo, it creates
work for others. Others who have enough work already without your help,
thank you.
There is a major difference between doing a global changes involving
few dozen or hundred packages when they are maintained, and having few
dozen more unmaintained packages to care for. The changes already
require a lot of effort, you know.
Now, there's a significant difference between lastriting unmaintained
packages at treecleaner's leisure and having a clean tree to work on,
and having to figure out how many of the packages blocking some global
change are unmaintained and if they can be cleaned, and cleaning them
while doing something completely different, then checking again,
then...
I completely do not understand why having "old" software in tree is
a problem, if such software have no serious issues and is not
blocking major progress. If software _is_ sufficiently broken, then
indeed move it to graveyard.
Right now, we have over 1500 unmaintained packages. Please tell me, how
that speaks of Gentoo? Because as far as I can see, we have 1500
packages which nobody looks after unless forced to.
You say that there are no bugs in those packages. How do you know? You
don't know unless you test it, and no maintainer means nobody is known
to test it regularly. The package can be pretty much completely broken
and we'll not know unless someone tests it.
Now, as long as package is in ::gentoo it is somehow officially
supported. Which means it pops up for user when he is looking for
something, and he assumes it's going to solve his problem. This is good
if it works. But considering it's unmaintained, nobody's testing it.
So the package might work, or it might not. It might have major
problems but nobody may notice them before user learns about them
the hard way. If he reports a bug, the bug goes to /dev/null, unless
some developer accidentally notices it and decides to fix it. Or just
lastrite the package.
More often a given package does not work for a noob-to-gentoo but and
old hack can make it work. I've seen tons of evidence for this on
gentoo-user over the last 12 years....
Let me summarize the user experience. User was looking for a good tool.
Instead, he found a well-advertised unmaintained old piece of software
that promised to solve his problems and instead created more problems
for him. Nevertheless, he decided to be a good user and reported
the bug. Then he learned that nobody cares to fix the bug, the package
is long forgotten, and all his effort was for nothing.
From a tree-cleaner prospective, you might be correct. As a gentoo-user,
and one that responses to many of the ML queries, there is a full
spectrum of experiences you are not accurately characterizing, imho.
Then he has to look for an alternative... and he starts to wonder how
to filter out those unmaintained packages because he'd rather use
something that somebody has really tested in the last 5 years.
Don't stop there. Users soon learn about overlays and a wide variety of
packages contained in those, as well as sabayon, calculate, coreos and
surely more to come (flatpak?). After a while you learn (after some
pain) which overlays and ebuild sources you can trust and use software
from. Just look at the tragic status of 'java' on gentoo, despite the
heroic efforts of many devs and users. Granted much pain with java is
directly attributed to Oracle, but many of us need java. Personally, I
add overlays (now about 10 currently) from devs I follow && trust. The
current gentoo tooling does not work for discovery details on overlays
run by devs. Example try 'equery m <package>' for an overlay you are not
familiar with.
So you are correct in what you have detailed above. Still, I do not see
that as reason to take a chainsaw to the gentoo portage tree. Be
aggressive on new tools development/integration to solve these problems
and not aggressive on removing packages from the tree. Those removals
should be on a conservative basis. Label the packages with these
non-critical deficiencies but not removal, unless severely broken
or serious security issues exist.
I for one run lots of (security) broken codes on closed networks with
vendor products to test. You think our gentoo tree has issues? You
should start probing and popping industrial products, some on 2.2 linux
kernels and insufficient hardware resources. Old codes on gentoo match
up very will with many currently selling products, just so you know.
I like old codes, that is for sure, and the graying of codes does not
mean they are useless. Far from it. ymmv.
hth,
James
