Curious to know, as a recent one I came across is man-1.6g. It is well known that as software becomes unmaintained, if it has vulnerabilities, they will not be getting fixed since the unmaintained packages are usually used in slackware as-is.


Has anyone done an audit? Or is that data available anywhere already?

If not I will try to create some of that info.

As you already know, you're the only person to care about that. Everyone else considers "if there weren't any problems reported with a package then there aren't any problems worth worrying about" to be valid.

Anyway, you're not wasting your time if you take on that project. Especially if you build your own packages for what you consider to be good replacements for the ones in Slackware, and then make your package building scripts (or the packages themselves) available to the community.

1 members found this post helpful.

You already received an answer from Pat Volkerding himself, i.e. the Slackware maintainer, as well as from other knowledgeable LQ members. Besides, you're yet to mention any actual issues affecting man-1.6g, hence I'm not sure what's the point of this thread.

1 members found this post helpful.

Technically speaking no Linux distribution keeps unmaintained packages for a time frame past a certain point. While a package can go unmaintained by the developers for years in the coding, it is simply either classed under maintenance mode or unmaintained but secure and stable and code. However, if the package can no longer be used for either a dependency or used outright as itself, then usually a package can be reviewed to see if patches exist to allow it to function, but if none exist, or if it can not be rebuilt or ran as a binary-only package, it can face the discretion of the OS maintainers to send it on it's way.

Packages come and go as software evolves. Often many packages are forked and new developers take over the project on their terms and set a new direction for the software.

Examples of this are found in many distributions like these packages:

Timidity > Timidity++
procps > procps-ng
ConsoleKit > ConsoleKit2

and this just names a few commonly known forked packages. There are times even packages simply are replaced by other packages.

Packages like man and man-db are a good example, but neither has really replaced the other. Both still work, much like TeTex and TexLive and such. Man is still used and considered long term stable, while man-db is actively developed, but likewise is stable.

However, the only real packages that never really go past a point of no return are binary-only packages that usually revolve around closed source software, and usually those never last too long.

It's all maintained. If there's an active upstream, contact them with bug reports. Otherwise, post here.

15 members found this post helpful.

man-1.6g has had patches posted here by Mancha (hombre de la mancha???).

http://sf.net/projects/mancha/files/...ke_a_boss.diff

Is there a list for packages that have been abandoned upstream? Do you agree or disagree that those would benefit from more attention?

Nope. Fee free to be the first to make that list.

1 members found this post helpful.

Hi!

I think all the packages are maintained in Slackware, I see many updates in the ChangeLog very often.

Maybe some software is not updated because doesn't need to be changed to work properly, as in life the cars still use tires even though we have airplanes, they do their job.

If someone needs something new, he can created, change something already done or wait for someone to do the job he can't do or doesn't want to do.

If you read this file /usr/doc/man-1.6g/README, you, maybe, can notice the way open source used to work; someone takes the source and changes it, if the change is good the community will take. Simple as that.

1 members found this post helpful.

Also, Rinnaldir, if you really care about this, then your best option (both for yourself and for helping the community) is to make your own package repo. Build your own packages, make the sources available, and put them in a public repo available over HTTP or FTP. Put in the metadata files that would allow everyone else to use the repo with slackpkgplus, and a README file about which of the official Slackware packages yours replace.

If you can't think of a place to host the packages, then think about getting an account here:

https://www.nearlyfreespeech.net/

3 members found this post helpful.

Not to go too far off topic...

I've been looking for a cheap and quality host for quite some time. Your recommendation looks excellent. Thanks for this!

I kept waiting for Rinndalir to notice the most obvious one, but he didn't so I'll help him.

LILO.