Date: Sun, 13 Apr 2014 17:46:26 +0200 From: Matthew Rezny <matthew@reztek.cz> To: freebsd-ports@freebsd.org Cc: marino@freebsd.org Subject: Re: FreeBSD ports which are currently scheduled for deletion Message-ID: <2340470.BGPyZMtLr7@desktop.reztek> In-Reply-To: <534A3AC0.6060201@marino.st> References: <2318877.ATaMhzlr5B@desktop.reztek> <534A3AC0.6060201@marino.st>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday 13 April 2014 09:20:32 John Marino wrote: > 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. > No, absurd is deleting a port just because its use is for a service that will go away at some indeterminate time in the future. As long as the MSN servers are still accepting connections, then there is a use case for the software which connects to those servers. Deleting it any sooner is jumping the gun. I mentioned it specifically to help make the case that the current means of marking ports deprecated is not effectively communicating the situation to the users of those ports. I really can't fathom how any of this leads to your conclusion that "they had to go". Was the port going to come kill your family if you didn't kill it first? No, there is no reason it "had to go". I have a suggestion for a way to communicate deprecations more effectively. At the end of a make update in /usr/ports and at the end of portsnap update, check all ports the user has installed and print a list of those that are marked for deprecation. If the port is installed and not changed, the use isn't going to see the deprecation in the port's Makefile because portmaster/portupgrade won't be touching it. The right time to alert is as soon as the ports tree is updated. There is no need for a separate script/program to run, because it won't get used. Another thing in periodic is just one more thing to ignore. As soon as the user sees reminders about one they don't care about, they will condition themselves to ignore it and will miss the one they do care about later. Same goes for a warning on portmaster/portupgrade runs, don't warn about deprecated ports on every invocation because the user sees it as another annoyance in the way of completing the task they are set out to deal with at that moment, which is almost surely installing/upgrading some port other than the one just marked deprecated. The correct time is on the update of the ports tree because that is the first time that information becomes available and it is sill a rare enough event not to be automatically ignored. > > 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 Ok, if you want to get personal, then I'll pull out the stops. I don't mind cracking skulls if that's what it takes... I'm not officially a maintainer on any ports for a few reasons. I have other areas where I consider spending my time more valuable, but if I have to waste it on port maintenance, I'll try to do so in the most efficient way. Unless I can directly commit changes to ports I maintain, then having my name emblazoned on the port makes zero difference in terms of what I can do. I already can submit patches as PRs and, more often than not, watch them linger without action. I've experimented with directly mailing patches to maintainers rather than adding one more PR to the database, believing that maybe that would speed the process because it's one less step to fix/update the port if there's not a PR to close (which might also be using someone else's time in directing the PR to the maintainer). Regardless of the approach, it is often slow to get a reaction if any. It's not my goal to be a maintainer of random ports, but if that's what it takes to keep them from being deleted, fine. Just give me the ability to actually maintain them. Well over a year ago, when 9.0 was fresh, I went through the effort of getting all the ports I wanted compiling with Clang (v3.2 iirc). Most of the issues were things that should be addressed upstream, so rather than flood the PR database, I went to the effort of submitting patches upstream via dozens of bug trackers, IRC channels, mail lists, etc. Some got good response, but unfortunately most were dismissed with a statement along the lines of "We only support GCC. Fix your weird compiler." Ironically, when I tried with modern GCC (either 4.6 or 4.7), far more ports were broken, and few of the ports that failed with Clang fared any better with GCC. The reaction of the upstream maintainers helped guide me towards alternate solutions for some software where the authors clearly had no desire for correctness. Examples: LibreOffice failed with both compilers, Clang was deemed strange, GCC issued were dismissed because I wasn't using Linux. Calligra not only had some errors, but a mess of style warnings that revealed many cases of reversed use of = and ==, which surely were responsible for a number of bugs that were either not yet fixed or not even reported. The critical difference is the Calligra team readily accepted my patch and thanked me for my efforts instead of dismissing my use case as unsupported. Shortly after, an Xorg update effectively broke DRI with UMS divers and the consensus seemed to be that it was more important to focus on KMS, which would be ready at some unspecified time, rather than look into what is likely a minor problem. Frustrated, I went back to the Windows ghetto for another year. When my Windows install decided to eat itself, 10.0 was around the corner and I decided to revisit FreeBSD as a desktop. It took some months, but using a mix of new Xorg and stuff from Xorg-dev-experimental repo (primarily Mesa 10), I have something usable and almost stable if I just ignore the console. I'm still not convinced syscons needs to be replaced as it's so close to working. Using the vesa driver for console, it's totally fine and it's just Xorg with issues (can only start up with KMS drivers once per boot). I'd still like to create a separate UMS graphics stack for independent maintenance as there is plenty of hardware in use that will never be supported by KMS (which isn't even fully baked yet). Thus far, I've probably spent more time arguing the merits of doing it than it would take to actually do it, but I've not yet gotten any acceptance of the idea. Everyone still wants to burn it with fire. With the graphics situation somewhat addressed, I've been able to put some time towards various ports I'd like to keep using. I'd prefer to go split up the Xorg and Mesa ports to preserve support for "legacy" hardware before it gets completely deleted, but I can hardly get acceptance of that idea. Everyone involved seems dead set on just wiping out everything. Having options or even separate ports would be too much work apparently, even if someone else (me) was maintaining them. If I'm told my efforts are going to be for nothing, do you think I'm terribly motivated to exert the effort? I could just try splitting everything, but I can't commit it, and even if I could submit it to someone else who would, all signs point to premature deletion of that work. Now, time for some recent examples (PR's filed this year and related events): I submitted bin/185777 with a patch to Clang which was directly sourced from upstream. It would be part of the the next release, but that was months of and the issue was a show stopper on a multitude of machines I have in use. 2 weeks to commit the patch to head, another 2 to MFC to 9/10-STABLE. Not great response time, but acceptable. I might expect some review if it was a patch I authored, but considering I had cherry picked it from upstream's repo and cited the commit, it should be a no-brainer. Thank tyou dim@ for taking care of this one and thank you again for looking into a separate Clang bug I submitted to upstream's tracker. I submitted ports/186529 in regards to a simple plist error. The maintainer responded in 2 days with an improved patch. It took another week for that to be committed. I had it fixed locally, but anyone else using XBMC without MySQL (which is not needed for typical use, only to share a single library between multiple instances) would have trouble installing. Bravo to the maintainer for fast action. Unfortunately, this is perfect evidence that being maintainer is not enough. Some else who is sufficiently blessed (posses a commit bit) has to actually commit the patch from the maintainer. Submitted ports/186547 but got no response. 10 days later I found the port had been updated and the problem was resolved. I noted such but the PR is still open. Somebody can go close that, if anyone actually cares. Evidence submitting a PR is sometimes totally pointless. Submitted ports/186790 regarding flex conflict. Response was that it was a problem with the particular port and not flex itself. Two days later I find another port breaking in the same way, thus pointing the finger back at the flex port. Eventually worked around after a week, but I'm not sure the workaround committed is ideal. I submitted ports/186792 regarding a problem with unbound and libevent dependency. It needs libevent14 even if the option is set for libevent20. Closed as can't reproduce. I provided direct evidence, libevent20 installed, libevent14 not installed, port failed to build. Install libevent14, port builds and installs. The response is that I shouldn't use portmaster and try again with no libevent installed. I already did all that before I filed the PR as part of debugging the issue. I filed the most concise proof of problem I could. Portmaster is not magically breaking the process, it behaves the same with direct invocation of make. I know the workaround, I will not waste more time trying to convince maintainer the port is busted. Someone else who cares more can pursue this. Unbound is in base if I needed it. This port was installed only to satisfy a (possible stale) dep in another port. Wasted time. I use QupZilla and was pleased to see the 1.6.3 release notes listed FreeBSD build fixes amongst the changes. Imagine my surprise when I update ports only to find it sitting at 1.6.1 and marked BROKEN. WTF?!? BROKEN was set the same day 1.6.3 was released, reason being unfetchable. Uhm, hello, upstream made a new release which incorporated half our patches, we had better update the port to use that version, not mark it BROKEN. The only thing BROKEN is the brain of the person who set that flag, one (very aptly named) rm@. I submitted a PR (ports/186810) with the patch, and exerted a good deal of effort to remain calm in doing so. The maintainer approved and the patch was committed. Fortunately this was quickly acted on, likely many people use this port. However, the maintainer was not the one who committed the change, and I'm not sure he has he the ability to do so. A couple weeks ago I as looking into the QupZilla project in depth, communicating with the author and some of the contributing developers. I couldn't help but notice some handy optional integration which is not exposed in the port. I'd like to have the KDE integration (use of KWallet), so I added an option to the port. Not being one to half-ass a job, I also added GNOME integration (use of GnomeKeychain) even though I will never use that option. Doing that forced me to look at the plist more closely , which revealed that I had neglected to add a few additional translations in my prior patch. I decided to experiment with more direct communication and sent the patch for options enhancement plus plist fixes directly to the maintainer a week ago. No response. I guess I should open a PR to track this. The 1.8.0 release is not too far off and I won't be surprised if I'm also submitting a PR with patch for that update when the time comes. I really don't agree with the author of FileZilla on many points, but nonetheless, it is one of the better GUI FTP packages still maintained. There were some arguably better options for FTP clients which unfortunately died with Qt3. I can only assume the authors were as dismayed with KDE4 in it's early days as I was and just didn't bother to port their software to Qt4 as a result. So, for better or worse, I'm using FileZilla. I'd at least like to use a recent version, one without multiple security vulnerabilities. The version in ports is more than a year out of date and contains multiple vulnerabilities. I submitted ports/186885 to request an update, including the minimal patch I'm using locally to install the current version. There has been no reply whatsoever from the maintainer in the 2 months that have elapsed since then. This is a port that has NO_STAGE set, so if that is mandatory, then perhaps this port should be deleted? I can't imagine a favorable response from that course of action. I'm sure there are many users of FileZilla, blissfully unaware of the vulnerabilities in the version they have, who don't give a damn if the port doesn't support staging because they have it installed and working. I prefer KVirc, but I noticed that Konversation had a new release, so I decided to give it a try as KVirc isn't exactly a shining example of stability. It was already 2 months after the release of 1.5 when I submitted ports/187720 with a patch to update it. I had to make the patch locally to test the new version. I wasn't sure I would even use Konversation or stick with KVirc, but since I had made the effort to do the update, I shared my work. It took a little over a week to be committed along with improvements. Thank you makc@ for acting in a reasonable time. I know you've got a lot on your plate with KDE overall so perhaps keeping up with related software updates is too much. I know the gecko team does updates of all the related ports in one go. I'm not a fan of the direction Mozilla is going, but I'm still a Firefox user nonetheless. For personal reasons, I had not immediately updated Firefox ESR from 24.2.0 to 24.3.0 in a timely fashion, nor had I been using Firefox at all. After the update, I went online with the new version and a number of extensions were updated in the background without confirmation. The only hint this happened was one of the updates created a new tab to show release notes, interrupting what I was doing. With minutes, the browser crashed and would not start again without crashing. Starting with addons disabled didn't help. Profile corruption, again! I had just been through this dance a month prior (corrupted blocklist XML file had removed an important extension and it took over a day to remove all traces of the blacklisting, one of three profiles affected). Once again, I found myself in #firefox on moznet seeking assistance, but only after I had switched profiles only to see a second profile suffer a similar fate. One of the first suggestions was to try updating to 24.4.0, which was done and would be announced as released the next day. Rather than wait, I made a trivial patch to the firefox-esr port to update it and try my luck. Of course, that made no difference in regards to my problem. Ultimately, after two days of debugging with no useful input from any mozillians, I figured out the two bad profiles had a corrupt certs8.db (a BDB file 52x the correct size, identically corrupted in 2 of 3 profiles) that was fixable by copying the file from the one good profile. Since I had made an update patch, I submitted ports/187725 as an experiment to see what the response would be. There was no response. The gecko ports were all updated a half day later, but nothing was done with my PR, so 3 days later I made a followup saying it could be closed. Only then was there some action, a simple close with no comment. There really was no need for me to file this particular PR, but the time wasted for the experiment to check responsiveness of gecko@ was nonexistent compared to the time invested to fix my Firefox profiles, again. When I tried to install Inkscape, I found a compilation bug. I reported it upstream as it is their responsibility. It turns out it was already found, but described as an Xcode 5 problem rather than a Clang 3.4 problem. It was only upon my dupe bug filing (with more accurate description) that the applicable patch was committed to upstream's repo. They have it slated for inclusion in the next release, but without even a loose target for when that will be, I decided it would be good if we had a patch so that anyone using Clang 3.4 (that is, anyone on HEAD or 10-STABLE) can build Inkscape. I am active on IRC and frequently converse with kwm@ so I mentioned it to him directly. He asked me to email the patch and said he would commit the next day. It has been more than a week now and there is no change to the Inkscape port thus far. Should I file a PR to track this, or would that just be one more thing on his overflowing plate? I believe I'm lending a hand to the best of my abilities given the current situation. I would be willing take on maintainership of some of the ports I had had to fix over time. I will take cfv right this instant to ensure that it doesn't get deleted as that would just be yet more work to revive it and a waste of even more of my time. I would prefer to be able to actually commit my work on it so I don't have to sit and wait for someone else to get around to it. I've seen enough examples, some of which I've mentioned with specifics, of maintainers who can't effectively maintain because they can't commit. While I appreciate the gated access to commit to src, forcing a system of checks and ensuring at least some peer review, I cannot say the same practice makes sense for ports. I see plenty of ports with maintainers that are not responsive or not able to respond. At the same time, I see plenty of threads on this ML from people who with to help a port but don't know how. I must admit that I don't know how either since I've tried more than one way and have yet to find any way to effectively contribute with any assurance my efforts are not for nothing. A more open repository for ports would be benefit as I see it. Perhaps a separate public-ports repo which essentially anyone can commit to in order to open the gates. The smaller number of people with a commit bit could cherry pick from the public repo. Those willing to take a little risk, could use the public repo so supplement the primary repo. In summary, if you want me to maintain some ports, then lower the barrier to entry and don't make me waste my time justifying the existence of ports I use or maintaining local patches to keep the zombies alive after they've been deleted without sufficiently informing the userbase. In just the time wasted on this thread, I could have fixed more than one of these ports. Regarding staging specifically, I mentioned that as the most recent sweeping infrastructure change. I understand the benefit of staging and wish it had been done a long time ago. The point I was trying to make is that it is not yet accepted and there are plenty of people who see it as one more hassle to maintainership, or one more thing they need to work around to just keep stuff working the way it has been for them. Those who were responsible for implementing it should have expected that sort of response and should be prepared to take some of the burden. Just passing the buck risks driving some maintainers away if it looks like it's more effort than it's worth. Marking ports for deletion just because they aren't stagified yet is even worse as it greatly reduces the chance of anyone stepping up to maintain it. That loss is the self-inflicted injury. Putting aside the question of who is responsible to stagify ports, the more pressing question is why is it now mandatory to have staging in all ports to the point that lack of staging support could be considered grounds for deletion? The ports without staging will build and install exactly as they always have. They won't get the benefit, but they won't impose any new harm. If it is a matter of difficulty building binary packages, then just don't build packages for ports that don't have staging. The lack of a binary package may help draw attention from users and a maintainer may materialize without having to mark the port deprecated. In fact, someone who sees the lack of a binary package and is willing to be a maintainer, may also be someone who would not do the same if they saw the port marked as deprecated because they would feel they would be facing an uphill battle in the latter case. Personally, the question of binary packages is meaningless as I ceased to use those the instant I learned how to build from ports, which was probably around 1999, so that put me in the camp of staging is nice and all, but this shouldn't be mandatory, at least not yet. I had planned to close by playing devil's advocate, listing all ports marked NO_STAGE and calling for their immediate deprecation. However, that list is so long that it would be truly absurd. It would help my point that simply lacking staging is an absurd excuse to deprecate a port, but the list is so long that it would substantially increase the risk the rest of the message goes unread. Current count in my local ports tree is 4983 ports are NO_STAGE. The total number of ports is listed at 24387 at the moment, so that would be >20% of all ports that should be immediately deprecated if we are to take a hard stance on requiring staging. The 221 ports listed in the original message only represent 4% of the problem ports, or <1% of total ports. It hardly makes a difference in the grand scheme of things. Keeping these ports is worthwhile if you consider the cost of doing so (nothing) against the cost of the potential ill-will created by ignoring the userbase and deprecating/deleting for questionable reasons ports that are still in use. Over and out.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2340470.BGPyZMtLr7>