| View previous topic :: View next topic |
| Author |
Message |
beandog
Bodhisattva
Joined: 04 May 2003
Posts: 2072
Location: /usa/utah
|
 Posted: Fri Jul 21, 2017 8:03 pm Post subject: Opinions: when is it okay to punt old packages from portage? |
 |
|
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. dvds | blurays | blog | wiki |
|
| Back to top |
|
 |
Fitzcarraldo
Advocate
Joined: 30 Aug 2008
Posts: 2034
Location: United Kingdom
|
| Posted: Fri Jul 21, 2017 8:42 pm Post subject: |
|
|
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, VIDEO_CARDS="intel modesetting nvidia".
Compal NBLB2: ~amd64, xf86-video-ati. Dual boot Win 7 Pro 64-bit.
OpenRC udev elogind & KDE on both.
Fitzcarraldo's blog |
|
| Back to top |
|
|
ct85711
Veteran
Joined: 27 Sep 2005
Posts: 1791
|
| Posted: Fri Jul 21, 2017 9:23 pm Post subject: |
|
|
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 |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54236
Location: 56N 3W
|
| Posted: Fri Jul 21, 2017 9:28 pm Post subject: |
|
|
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 |
|
|
R0b0t1
Apprentice
Joined: 05 Jun 2008
Posts: 264
|
| Posted: Fri Jul 21, 2017 9:37 pm Post subject: |
|
|
| 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 |
|
|
ct85711
Veteran
Joined: 27 Sep 2005
Posts: 1791
|
| Posted: Fri Jul 21, 2017 11:47 pm Post subject: |
|
|
| 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 |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3135
|
| Posted: Sat Jul 22, 2017 10:34 am Post subject: |
|
|
| 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 |
|
|
Fitzcarraldo
Advocate
Joined: 30 Aug 2008
Posts: 2034
Location: United Kingdom
|
| Posted: Sat Jul 22, 2017 12:56 pm Post subject: |
|
|
| 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, VIDEO_CARDS="intel modesetting nvidia".
Compal NBLB2: ~amd64, xf86-video-ati. Dual boot Win 7 Pro 64-bit.
OpenRC udev elogind & KDE on both.
Fitzcarraldo's blog |
|
| Back to top |
|
|
tld
Veteran
Joined: 09 Dec 2003
Posts: 1816
|
| Posted: Sat Jul 22, 2017 2:56 pm Post subject: |
|
|
| 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 |
|
|
dmpogo
Advocate
Joined: 02 Sep 2004
Posts: 3267
Location: Canada
|
| Posted: Sun Jul 23, 2017 4:31 am Post subject: |
|
|
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 |
|
|
The Doctor
Moderator
Joined: 27 Jul 2010
Posts: 2678
|
| Posted: Sun Jul 23, 2017 4:38 am Post subject: |
|
|
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.
Apologies if I take a while to respond. I'm currently working on the dematerialization circuit for my blue box. |
|
| Back to top |
|
|
devilheart
l33t
Joined: 17 Mar 2005
Posts: 848
Location: Villach, Austria
|
| Posted: Mon Jul 24, 2017 7:17 am Post subject: |
|
|
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 |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Mon Jul 24, 2017 12:42 pm Post subject: |
|
|
| 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 |
|
|
ct85711
Veteran
Joined: 27 Sep 2005
Posts: 1791
|
| Posted: Mon Jul 24, 2017 2:02 pm Post subject: |
|
|
| 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 |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20067
|
| Posted: Mon Jul 24, 2017 3:06 pm Post subject: |
|
|
| 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.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Mon Jul 24, 2017 3:28 pm Post subject: |
|
|
| 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 |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Mon Jul 24, 2017 7:00 pm Post subject: |
|
|
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 |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Mon Jul 24, 2017 9:44 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
ct85711
Veteran
Joined: 27 Sep 2005
Posts: 1791
|
| Posted: Mon Jul 24, 2017 10:11 pm Post subject: |
|
|
| 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 |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Mon Jul 24, 2017 11:59 pm Post subject: |
|
|
| 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 |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9679
Location: almost Mile High in the USA
|
| Posted: Fri Jul 28, 2017 4:16 pm Post subject: |
|
|
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/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
|
|
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
|
|
Gentoo Chat
