Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Opinions: when is it okay to punt old packages from portage?
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Gentoo Chat
View previous topic :: View next topic  
Author Message
beandog
Developer
Developer


Joined: 04 May 2003
Posts: 2032
Location: /usa/utah

PostPosted: Fri Jul 21, 2017 8:03 pm    Post subject: Opinions: when is it okay to punt old packages from portage? Reply with quote

Asking for a friend ... j/k ;)

I'm curious to get users' take on something, and I know it's subjective because the story is going to change for each package, but at what point does a user think it's okay to go ahead and punt an old package from the tree because it's just never used anywhere ... at all ... by anyone.

Here's an example scenario (some that I'm actually looking at):

There's an ebuild in the tree that is years old (8+). New packages have come out that replace it and are the standards, and it's been dead upstream for years, and it's never been used. There's no reverse dependencies on it. Homepage is dead. The tarball is hosted by a developer. The only purpose it's serving is that of being an academic reference if someone wanted to look at it. Oh, and it's marked as stable.

From a user point of view, I could see (and would argue), there's no reason at all to kick it from the tree. And I would ask, "what problem is removing it going to solve?"

From a developer point of view, things are a bit different. Said stable ebuild gets a few bug reports in there, that are rotting in bugzilla, often for years. There are easy fixes for it, but it is still an amount of work -- have to update the EAPI, make a few changes, possible review, discussion, commit and then going through a whole nother around of stable requests. All for a package that is just sitting there acting as an archive.

So I guess the question is, at what point is it not worth worrying about, re doing updates? I ask because a part of me thinks, "oh, there's this simple low-hanging fruit bug in zilla that I can knock out in five minutes," but then on the flip side, the question is, "but what if stabilization process finds that there is bugs?" Who is going to maintain this package if *new* issues come up?

In the past, I recall we'd use to put stuff in global package.mask and just see if anyone whined or not, and that typically worked really well, especially if you give some good lead time, and make an announcement / notice somewhere (mailing list, forums, blog post, whatevs).

Anyway, I'm curious what everyone else thinks.

(Please note that I'm not going to go on a treecleaning rage commit land adventure time joyride)
_________________
If it ain't broke, tweak it. packages | dvds | blurays | blog
Back to top
View user's profile Send private message
Fitzcarraldo
Veteran
Veteran


Joined: 30 Aug 2008
Posts: 1264
Location: United Kingdom

PostPosted: Fri Jul 21, 2017 8:42 pm    Post subject: Reply with quote

I start to get leery if a package has had no developer activity at all for two years. So, personally, I would not be bothered if a package that had neither been used anywhere for over two years nor been touched by a developer for over two years were to be pruned from the tree.
_________________
Clevo W230SS: amd64, OpenRC, nvidia-drivers & xf86-video-intel.
Compal NBLB2: ~amd64, OpenRC, xf86-video-ati, dual booting with Win 7 Pro 64-bit.
KDE on both laptops.

Fitzcarraldo's blog
Back to top
View user's profile Send private message
ct85711
Veteran
Veteran


Joined: 27 Sep 2005
Posts: 1261

PostPosted: Fri Jul 21, 2017 9:23 pm    Post subject: Reply with quote

I agree with Fitz, in if there is no developer activity for so long, it's getting to the point of considering it it's worth keeping. Now the part I would say is if upstream is still around and supporting the package and it just hasn't needed any fixes then I'd consider it still active.

Frankly if it's no longer supported upstream and/or upstream is dead/gone; then it's probably better to go ahead and give it last rites.

Keeping it around in the tree for only academic/historical reasons is not any reason to keep it.

Side Note: I've mentioned before, that I thought there was some old bug report still open that needs to be closed out; frankly in the part of the package in question is no longer supported period. Some of the bug reports, I am talking about are like these ebuild requests that hasn't been touched in almost 10+ years...

Some examples, would be like:
Bug 97934 kevedit-0.5.1.ebuild (New package) - 2007
Bug 162933 games-fps/tyrquake-9999.ebuild (New Package) - 2007
Bug 129478 Super Mario War - a supermario deathmatch game - 2007

Are these even applicable any more, what about it's dependencies? Is there any reason to keep these bug reports around, as obviously no one has bothered to pick these ebuilds up, or at least closed the bug report if they did.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 38399
Location: 56N 3W

PostPosted: Fri Jul 21, 2017 9:28 pm    Post subject: Reply with quote

beandog,

With all those problems, mask it and see if anyone complains.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
R0b0t1
Tux's lil' helper
Tux's lil' helper


Joined: 05 Jun 2008
Posts: 148

PostPosted: Fri Jul 21, 2017 9:37 pm    Post subject: Reply with quote

Fitzcarraldo wrote:
I start to get leery if a package has had no developer activity at all for two years.
Just because there has been no need to update the software does not mean the software is obsolete. The majority of the code in packages like coreutils probably hasn't been touched in far longer than that.

I think languishing bugs in the tracker for old packages can be a good indication that a package isn't being actively used, but that really depends on the type of bug it is. The majority of users might not encounter a bug; if the bug was obvious it wouldn't have ever become a bug because the developer would have encountered it. If it is possible to figure out if anything has been removed due to perceived obsolescence and then added back I think that would go a long way towards determining the best policy.

A lot of developers seem allergic to wasted effort, but a lot of the time it is hard to see where the effort is actually wasted. E.g. I asked the GCC developer who removed the Java front end why they did it, and never actually received any comment on what extra work the Java front end was causing - just the vague assertion that it was old and causing more work. The original post seems to justify how old packages can cause work.

My preference would be to never remove functionality unless the package actively interferes with newer packages which are under active development. Unresolved bugs can probably be left as such until someone cares. Some projects (like Firefox) seem to have a policy of keeping the bug tracker as clean as possible; unfortunately this seems to me like a great deal of valid bugs are closed because they can't be reproduced. It seems the better solution would be to keep them open so more evidence is gathered about the bug to possibly fix it later. Likewise the bug can be kept open but ignored so it is obvious it is a recognized problem.

The above are the two pitfalls in maintenance policy to consider. At the moment Gentoo doesn't seem to suffer from either of them, so proceeding as normal is probably a fine solution.
Back to top
View user's profile Send private message
ct85711
Veteran
Veteran


Joined: 27 Sep 2005
Posts: 1261

PostPosted: Fri Jul 21, 2017 11:47 pm    Post subject: Reply with quote

Quote:
Some projects (like Firefox) seem to have a policy of keeping the bug tracker as clean as possible; unfortunately this seems to me like a great deal of valid bugs are closed because they can't be reproduced. It seems the better solution would be to keep them open so more evidence is gathered about the bug to possibly fix it later. Likewise the bug can be kept open but ignored so it is obvious it is a recognized problem.


In some parts, I can see where you are getting at, in over-aggressive on bug closing can be detrimental. On the other side, having open bug reports for, say version 10.x when you are on version 40+ makes no sense. Personally, I'd suggest, more of like bug reports that have not had an update, say like 5 years, to close. This helps keep some of the older bug reports somewhat relevant still to the current code. This is going by the assumption that the package's code has changed enough in that time span, that similar issues is more likely caused by something different. Of course, this time limit could be adjusted, for some packages that are very slow on changes, to go ahead and expand the time frame (like maybe dbus or even xfce, which you maybe get a new version once a blue moon). Though I would also, say like the bug reports for simply just a new ebuild to be added to the tree, to close after an year of inactivity. The reasoning on this, is that new ebuild requests that old, is probably unlikely going to be picked up by a maintainer in the first place or is no longer relevant anymore.
Back to top
View user's profile Send private message
szatox
Veteran
Veteran


Joined: 27 Aug 2013
Posts: 1412

PostPosted: Sat Jul 22, 2017 10:34 am    Post subject: Reply with quote

Quote:
In the past, I recall we'd use to put stuff in global package.mask and just see if anyone whined or not, and that typically worked really well, especially if you give some good lead time,
Yup, I've been doing similar things myself. Taking down some service tends to make it's owner to miraculously appear. If he does not appear in a month or two, it's probably not needed.
Quote:
I start to get leery if a package has had no developer activity at all for two years.
Nope. Some things are simply meant to be created, and then they are considered "complete".
"Complete" and "abandoned" are not the same thing, even though they share that trait of not being developed anymore.

Quote:
From a developer point of view, things are a bit different. Said stable ebuild gets a few bug reports in there, that are rotting in bugzilla, often for years. There are easy fixes for it, but it is still an amount of work -- have to update the EAPI, make a few changes, possible review, discussion, commit and then going through a whole nother around of stable requests. All for a package that is just sitting there acting as an archive.

So... Looks like the ebuild could be dropped when it fails due to changes in the environment. It would still be nice to have some way to install such an ancient environment though. With portage tree in a git repo, having an old version of emerge available could do the trick. Not all systems are equal. If you just need one tool from the past, you can freeze its image and keep using it for ages. A bad thing to do in general, but - a as always - exceptions apply.
Back to top
View user's profile Send private message
Fitzcarraldo
Veteran
Veteran


Joined: 30 Aug 2008
Posts: 1264
Location: United Kingdom

PostPosted: Sat Jul 22, 2017 12:56 pm    Post subject: Reply with quote

szatox wrote:
Quote:
I start to get leery if a package has had no developer activity at all for two years.
Nope. Some things are simply meant to be created, and then they are considered "complete".
"Complete" and "abandoned" are not the same thing, even though they share that trait of not being developed anymore.

I know. The trouble is, most packages do not exist in a bubble; they rely on other packages... that get modified over time and may thus result in a breakage in the untouched package somewhere down the line. Over the years I have had to stop using several useful applications that the developer had not touched for several years and that had stopped working fully or partially due to upgrades to third-party libraries, DEs, etc. Hence my use of the word 'leery'. Also, please note the implicit Boolean AND in my original post:

Quote:
I would not be bothered if a package that had neither been used anywhere for over two years nor been touched by a developer for over two years were to be pruned from the tree.

_________________
Clevo W230SS: amd64, OpenRC, nvidia-drivers & xf86-video-intel.
Compal NBLB2: ~amd64, OpenRC, xf86-video-ati, dual booting with Win 7 Pro 64-bit.
KDE on both laptops.

Fitzcarraldo's blog
Back to top
View user's profile Send private message
tld
Veteran
Veteran


Joined: 09 Dec 2003
Posts: 1168

PostPosted: Sat Jul 22, 2017 2:56 pm    Post subject: Reply with quote

NeddySeagoon wrote:
beandog,

With all those problems, mask it and see if anyone complains.
I agree with this approach, which seems to often be what happens already. I occasionally get those emerge warnings with a note about a package being masked and slated for removal. It generally turns out to be something I installed a very long time ago and never use.

Tom
Back to top
View user's profile Send private message
dmpogo
Advocate
Advocate


Joined: 02 Sep 2004
Posts: 2374
Location: Canada

PostPosted: Sun Jul 23, 2017 4:31 am    Post subject: Reply with quote

It is instructive to look at /usr/portage/distfiles timestamps. You find that even on a fresh new system there are tarballs going back to 2006 or earlier.
Looking at that you immediately see that not every 'untouched' for a decade code is obsolete. My take on it - if it compiles, and not explicitly obsoleted by newer development, it should stay, perhaps masked.
Back to top
View user's profile Send private message
The Doctor
Moderator
Moderator


Joined: 27 Jul 2010
Posts: 2246

PostPosted: Sun Jul 23, 2017 4:38 am    Post subject: Reply with quote

My take is that is a judgment call based on the package. Something that is mature, useful, and doesn't have any (known) bugs is probably a keeper.

Something that is incomplete and dead upstream should probably be purged as upstream dies. games-rpg/sumwars, for example.
_________________
First things first, but not necessarily in that order.
Back to top
View user's profile Send private message
devilheart
l33t
l33t


Joined: 17 Mar 2005
Posts: 824
Location: Villach, Austria

PostPosted: Mon Jul 24, 2017 7:17 am    Post subject: Reply with quote

You could consider programs that:

1) are not mantained by upstream
AND
2) cannot be build because of changes in libraries the program depens on
AND
3) no one in this community is willing to patch it
Back to top
View user's profile Send private message
Tony0945
Veteran
Veteran


Joined: 25 Jul 2006
Posts: 1859
Location: Illinois, USA

PostPosted: Mon Jul 24, 2017 12:42 pm    Post subject: Reply with quote

devilheart wrote:
You could consider programs that:
...
2) cannot be build because of changes in libraries the program depends on
...
Very important. I see too many packages thrown to the curb because "nobody uses this". How nice to be officially nobody.
If it builds and runs, it stays. If the EAPI becomes obsolete, that's different. Then it can't be run without modification.

And I think pending drops should be more prominent in the forum. Most often I find out a package has been dropped after a sync when it's already gone. Now I tar up /usr/portage before syncing.
Back to top
View user's profile Send private message
ct85711
Veteran
Veteran


Joined: 27 Sep 2005
Posts: 1261

PostPosted: Mon Jul 24, 2017 2:02 pm    Post subject: Reply with quote

Why bothering taring up the portage tree, when you can easily retrieve any old ebuild that was in the tree through git. Considering git keeps track of all changes since the tree was transferred over, you can recover anything since then any time you'd ever want. Now, what you may want to backup is the distfiles directory so that you can find the sources easier. Even then, distfiles is not automatically emptied, so you only need to back it up before it's cleaned.
Back to top
View user's profile Send private message
pjp
Administrator
Administrator


Joined: 16 Apr 2002
Posts: 16395

PostPosted: Mon Jul 24, 2017 3:06 pm    Post subject: Reply with quote

NeddySeagoon wrote:
beandog,

With all those problems, mask it and see if anyone complains.
++

If someone did come out of the woodwork, maybe they could help maintain it in an overlay.


In general though, I'd say when an abandoned package becomes "difficult" or problematic to maintain.
_________________
Here's another unfortunate pack of mutants who ought to be penciled in for a sudden visit from the angel of death.
-- Carlin
Back to top
View user's profile Send private message
Tony0945
Veteran
Veteran


Joined: 25 Jul 2006
Posts: 1859
Location: Illinois, USA

PostPosted: Mon Jul 24, 2017 3:28 pm    Post subject: Reply with quote

ct85711 wrote:
Why bothering taring up the portage tree, when you can easily retrieve any old ebuild that was in the tree through git. Considering git keeps track of all changes since the tree was transferred over, you can recover anything since then any time you'd ever want.


If you are a git guru. I find reading git logs as excruciating as reading XML. For a while I maintained a git based overlay on my local LAN. It was just too much trouble deciphering why it wasn't working. Now I just use scp from the master repository.
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 5740

PostPosted: Mon Jul 24, 2017 7:00 pm    Post subject: Reply with quote

If your sole reason to look at it is because of its age, then it's a bad reason to remove it.
If you were having real reasons, you wouldn't just ask yourself if it's good or bad to remove it no?

If you start ripping off old packages because they are old, i think games category will be on a diet.
Back to top
View user's profile Send private message
Ant P.
Advocate
Advocate


Joined: 18 Apr 2009
Posts: 4287

PostPosted: Mon Jul 24, 2017 9:44 pm    Post subject: Reply with quote

I'm pretty sure I have a few packages like that installed...

Is it likely to have high-profile CVEs at some point in the future if it's left lying around? If not, probably not worth the effort to even remove it.
_________________
Your PID1 sucks // runit-scripts
Back to top
View user's profile Send private message
ct85711
Veteran
Veteran


Joined: 27 Sep 2005
Posts: 1261

PostPosted: Mon Jul 24, 2017 10:11 pm    Post subject: Reply with quote

Quote:
If you are a git guru. I find reading git logs as excruciating as reading XML.

Honestly, I am no way near to being a guru on git, if anything, I am more of still a noob on it. I have trouble just committing and cloning a repository let alone anything else. As far as reading the logs, is difficult either way we look at it. Quite frankly, there is nothing controlling what the devs put down in the commit message. This problem was still an issue before portage tree moved to git, so nothing has changed there. The main difference is now, devs can't just make a change without putting something down, mean no more silent changes. Generally, I typically ignore the commit messages and look at the files affected and the date (helps if you about when it changed, to go to the correct commit right away). Once you find when the package was changed/removed you can have git show you the tree from that point of time and download the file(s).

Edit: Honestly, I do agree that the games category would almost die away; as it seems there are only a few devs that maintain some of those packages as it is. One thing I have been noticing is that it seems there are fewer devs/maintainers around to maintain packages anymore. A couple years ago it used to be fairly straight forward that you can make a bug report mentioning of a package got and update, and it would be fixed in a week or 2, now it seems you end up waiting months or longer, if a dev bothers to update the package. Anymore it seems, it's not even worth the effort to submit a bug report, even to get a new package added to the tree. So, some people been more of directing people away from the main tree to an overlay, because they at least have an updated ebuild.
Back to top
View user's profile Send private message
Tony0945
Veteran
Veteran


Joined: 25 Jul 2006
Posts: 1859
Location: Illinois, USA

PostPosted: Mon Jul 24, 2017 11:59 pm    Post subject: Reply with quote

ct85711 wrote:
I have trouble just committing and cloning a repository let alone anything else. As far as reading the logs, is difficult either way we look at it.

I'm really glad that I'm not alone!


ct85711 wrote:
One thing I have been noticing is that it seems there are fewer devs/maintainers around to maintain packages anymore. A couple years ago it used to be fairly straight forward that you can make a bug report mentioning of a package got and update, and it would be fixed in a week or 2, now it seems you end up waiting months or longer, if a dev bothers to update the package. Anymore it seems, it's not even worth the effort to submit a bug report, even to get a new package added to the tree.

For sure. Or you submit a bug report and after a month or so, it gets answered with "NOT REPRODUCIBLE. WON'T FIX!". A few of those and you figure "Why do the work to make a credible bug report with patches and all? Why not just make my own overlay and mask the portage tree?"
Back to top
View user's profile Send private message
eccerr0r
Watchman
Watchman


Joined: 01 Jul 2004
Posts: 5910
Location: almost Mile High in the USA

PostPosted: Fri Jul 28, 2017 4:16 pm    Post subject: Reply with quote

I do wonder about packages like mail-filter/procmail... I still use it. It's a very old MDA and virtually unmaintained now?

Curiosity if fetch logs from distfiles.gentoo.org is used to tell whether a package is still being used or not... It's definitely not the most accurate method due to not being updated when everything's fine and dandy among other reasons, but at least it still gives an idea.
_________________
Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSD
What am I supposed watching?
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo Chat All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum