Questions about deprecated packages

I'm very pleased with FreeBSD 14, to which I recently upgraded. Almost everything runs smoothly, and what doesn't was rectified with a few tweaks here and there. However, as ever, I was a bit dismayed that some packages of programs that I use or play regularly (specifically, sweep, asedit, lbreakout, lbreakout2, xvt, gimmage, aqualung) that are without apparent defect are on the chopping block because they're abandoned, old, or both.

asedit and the lbreakout clones are undeniably old and long abandoned, but so too have been many other programs presently in the repos that I've used for years. Are they targeted because they're very unpopular or superannuated?
Moreover, gimmage and aqualung are deprecated for their reliance on GTK2, et cetera, but many other programs that I use rely on these libraries.
xvt (actually rxvt if memory serves) was an especial surprise, as I know it to be popular; urxvt is certainly an adequate, if not superior replacement, but I only wonder why. Is its retention simply unworthy of the trouble that it would or might entail?

This post is inquisitive, not critical. I have tremendous regard for maintainers. Whenever necessary, I don't at all object to the prospect of compiling some or all of these programs in the future from source if feasible. Nathless, I am curious about the specific criteria by which packages of unbroken programs are deprecated. Is it codified in a document, or are these packages treated in address of individual circumstances? This is something I've wondered since a game that I enjoy (xevil) was purged from the repos and I was forced to compile it from source.

Conversely, I was almost shocked that so many programs requiring python27 are still only deprecated! XD

Thanks in advance for any helpful replies!
 
Generally:



In addition, there's the FreeBSD Packages Management Team <https://www.freebsd.org/administration/#t-pkgmgr> (at a glance, some overlap).


Maybe still in the tree to build Chromium and the like.

For other specific ports, use FreshPorts to identify the maintainer (if any); and click the version number near the head of the page to jump to #history.
 
Note that the version of FreeBSD has nothing to do with ports/packages. Those ports that have been deprecated are deprecated on ALL supported versions of FreeBSD. There is only one ports tree and all supported versions of FreeBSD use that one and only ports tree.

This is usually a source of confusion with new users. Ports/package versions have nothing to do with the FreeBSD version (with some notable exceptions like the DRM drivers).
 
asedit and the lbreakout clones are undeniably old and long abandoned, but so too have been many other programs presently in the repos that I've used for years. Are they targeted because they're very unpopular or superannuated?
I just looked at lbreakout for now and instantly found a lengthy explanation in the latest commit message. In this case, it won't even be deleted because indeed, it still works fine and there seem to be no other important concerns either. It's deprecated because upstream says so and offers a more modern replacement.

Moreover, gimmage and aqualung are deprecated for their reliance on GTK2, et cetera, but many other programs that I use rely on these libraries.
GTK2 has been deprecated upstream vor a very long time now. Without any active development, there's an increasing risk for security issues and it's also likely to require more and more local patching for compatibility with other stuff that keeps moving on. Upstreams using GTK should really move to a newer version ... if they don't, they're probably dead.

xvt (actually rxvt if memory serves) was an especial surprise, as I know it to be popular; urxvt is certainly an adequate, if not superior replacement, but I only wonder why.
Most likely the same: upstream isn't maintained and there is a more modern drop-in replacement. And in this specific case, a terminal emulator that doesn't fully handle Unicode is more or less useless today.

Conversely, I was almost shocked that so many programs requiring python27 are still only deprecated!
This was shocking to many. An abandoned language implementation is really a red flag, security issues are very very likely here. Still it couldn't go as long as lots of "must have" software still needed it (and if only for building...). Relying on some language for your builds that introcues breaking changes that are sometimes hard to follow for your existing code probably isn't the best choice in the first place, but I won't go into more ranting here ... ?

All in all, you do need some lifecycle management for ports. They won't disappear without warning normally, that's what deprecation is for. You want to avoid unnecessary security risks. You want to avoid something becoming increasingly unmaintainable because of compatibility issues. You want to avoid "pointless" port because a full replacement is already there. etc ....

To know the specific reason something was deprecated or removed, you'll almost always find sufficient explanation in the commit messages. Paying attention to these (especially clearly explaining the "why") is part of the commit guidelines.
 
For other specific ports, use FreshPorts to identify the maintainer (if any); and click the version number near the head of the page to jump to #history.

I will; thanks for the advice. I browse the deleted and deprecated sections there every month or two.

There is only one ports tree and all supported versions of FreeBSD use that one and only ports tree.

For whatever reason (probably bad experiences with certain Linux distros and problems encountered when transitioning from i386 to AMD64), I've retained this vague, lingering, rather stupid notion that many ports and packages are accorded differing priorities and availability in varied versions and architectures. Thanks for clarifying what should've been obvious.

It's deprecated because upstream says so and offers a more modern replacement.

Yeah, I consulted LGames's website for details; I hadn't visited for a couple years.

Upstreams using GTK should really move to a newer version ... if they don't, they're probably dead.

Duly noted. I wasn't even aware that GTK2's been obsolescent for so long.

And in this specific case, a terminal emulator that doesn't fully handle Unicode is more or less useless today.

Again, this is a factor that I should've considered. It prompts certain questions regarding xterm that should be asked elsewhere....

An abandoned language implementation is really a red flag, security issues are very very likely here.

After a few years of (frankly entertaining) drama expressed here and elsewhere regarding its deprecation and that of so much related software, I was stupefied to actually see it listed in FreshPorts's deprecated category.

Relying on some language for your builds that introcues breaking changes that are sometimes hard to follow for your existing code probably isn't the best choice in the first place, but I won't go into more ranting here ..

As a clueless layman, I can only observe that I had four versions of Python installed on a machine on which programs that I used regularly relied, just shy of a year ago. XD

To know the specific reason something was deprecated or removed, you'll almost always find sufficient explanation in the commit messages. Paying attention to these (especially clearly explaining the "why") is part of the commit guidelines.

Will do. Thanks to everyone for so much helpful information!
 
It prompts certain questions regarding xterm that should be asked elsewhere....
JFTR, the times when xterm didn't support Unicode are long gone as well. Actually, xterm is a very capable terminal emulator, I switched back to it from urxvt after hitting some font-rendering issues in urxvt I didn't manage to solve.
 
Back
Top