Date: Sun, 13 Apr 2014 07:21:18 +0200 From: Matthew Rezny <matthew@reztek.cz> To: freebsd-ports@freebsd.org Subject: Re: FreeBSD ports which are currently scheduled for deletion Message-ID: <2318877.ATaMhzlr5B@desktop.reztek> In-Reply-To: <53458CF0.4080900@marino.st>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 4/9/2014 19:56, Christian Weisgerber wrote: > > On 2014-04-08, Tijl Coosemans <tijl at coosemans.org> wrote: > >> Then, once it is reasonable to assume that a port is unused it is first > >> marked deprecated which gives users some time to step forward. > > > > There seems to be the general problem, seen again and again, that > > users only learn of a port's deprecation status when it is finally > > removed and not in the preceding grace period. > > I find this highly doubtful. > I will give you that binary package users won't know the package is > deprecated or their is even a problem until the package is no longer > available, but somebody is going to see if if they build from source. > > OTOH, if somebody only rebuilds every 15 months, the deprecation period > could come and go. I guess the ultimate solution is that "pkg info" > shows packages that are deprecated. > > In the meantime -- it's still a non-problem as long as "svn revert" works. > > John I call bullshit on that claim. I'm in full agreement with Christian on this. I just happened to look at the list this time around because there was a long thread forming which suggested something was flagged for removal that shouldn't be, and I recently got surprised by the overzealous removal of another port. Going through it I see several that I have used and would be surprised to find gone only because there's no new releases upstream. Is it impossible that a piece of software is done and needs no changes to remain useful? NO How many users look at these long lists to see if any of their software is in them? I have enough other details to track that I usually don't see any deprecation notice until the port just disappears. Example: I recently was surprised to find that Kopete lost MSN support and in fact libmsn had disappeared. It was only on a major KDE update that I noticed this, some 4 months after the port was deleted. So, I have to revert multiple things to restore simple functionality. Reason for removal was stated that MSN network has shutdown. No, it hasn't. Microsoft has been pushing people onto Skype for a year, but if you just connect with any 3rd party client you can still communicate with contacts using other such clients or who have merged their accounts with a Skype account. To be fair, libmsn itself had not been updated so it would not connect, but it wasn't for the reason stated. The only problem is it had not been updated and was still reporting itself as an old beta of the MSN client so it would get disconnected with a "get Skype" message. Updating the version it reports to same as libpurple claims fixes that, which is a one line patch. But to even make that change, first I have to resuscitate the port. Then I have to go revert changes in Kopete port to make use of it. Figuring out when it was removed and how exactly to restore it took more time than fixing the only actual issue, a minor update that might have been made already had the entire port not been discarded prematurely. On this list I see cfv, which I've used for years, marked just because it's not maintained. It works great, it needs no changes. You want someone to bloat it with a useless non-feature to prove people still use it? I see there's a few other sfv checkers in ports tree, but then I have to go test all those, pick a suitable replacement, alter any scripts that call cfv to call the replacement, etc. Quickly looking at the options, all the others are less functional (two only do SFV, one does PAR, but not all the other formats cfv supports) and one of them is a GUI tool so useless for scripted invocation. Also on the list is cpupowerd, which even has a maintainer, marked because it's for the "ancient K8". Yeah, sooo old, ahem, I still have one of those boxes running and would prefer utilities for it not disappear. In fact, I have another four boxes with K7 CPUs still running. Just because it's old doesn't mean it's unused. In this case, old means it still works because the motherboards have some decent capacitors. I don't use XMMS anymore, but I did use it for years and agree with other respondents that the suggestion to use XMMS2 is a bad joke at best. At least there is an effort to fix that one already underway. I see xfm on the chopping block for lack of maintenance. Just last month we had two users on this ML discussing possibly updating that port. kdc2tiff, tiff2png, etc are simple image converters which, once working, really need no change so need no maintenance. Sure, there are more comprehensive tools that serve those functions. I'm not using them, but somebody, somewhere, has a workflow which depends on one of those and they won't be happy about having to change their scripts when one of their basic utilities disappears. > Hi Mikhail, > > I think the term "self-inflicted" is a little strong... we can't really > expect the tree to stand still. I would expect people to loudly > complain if their favourite port were dropped-- it's really not much > effort to bring back, and some do come back. > > If I have 1000 ports to fix, and decide to drop 50 of them because > they're ancient and probably unused, it's no effort to restore and fix > three if someone yells, and I've saved the effort of fixing 47 unused ports. > > Chris Actually, self-inflicted is pretty apt when a piece of software has worked without maintenance for over a decade but now has to be axed for lack of staging or whatever other recent infrastructure change has been made to ports. If you want to change infrastructure, be ready to clean up afterwards. Telling the users to do it will just lead to more "Staging, WHY?" threads. Consider this thread to be loudly complaining.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2318877.ATaMhzlr5B>