Date: Sun, 13 Apr 2014 09:20:32 +0200 From: John Marino <freebsd.contact@marino.st> To: freebsd-ports@freebsd.org Cc: matthew@reztek.cz Subject: Re: FreeBSD ports which are currently scheduled for deletion Message-ID: <534A3AC0.6060201@marino.st> In-Reply-To: <2318877.ATaMhzlr5B@desktop.reztek> References: <2318877.ATaMhzlr5B@desktop.reztek>
next in thread | previous in thread | raw e-mail | index | archive | help
On 4/13/2014 07:21, Matthew Rezny wrote: >> 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. Your example of MSN is absurd. MSN publicly stated their own messenger and service had a specific EOL which is long past. It also stated that it would end 3rd party support "sometime" in the future but refused to give an exact date, but still it wasn't thought to last more than a year longer than official EOL date. Those MSN ports were deprecated for months (which leads credence to the idea that marking deprecated isn't seen well), but they had to go. > > 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. > Staging is a strong, deal-breaking requirement. It is out of scope to rehash why that is here. Lack of staging by itself is reason to remove the port and if nobody is willing to do the maintenance, what is left? I did a query search on maintainer string in Freshports for "rezny" and "reztek" and was shocked to discover you don't maintain anything. (actually, this is a lie, I would have been shocked if the search returned results). Loudly complaining about a free service that one doesn't contribute to, what else is new? "You can't make an omelet without breaking some eggs" is apropos here I guess. John
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?534A3AC0.6060201>