On Tue, Jun 16, 2020 at 10:23:30PM +0000, Jóhann B. Guðmundsson wrote:
The solution to this problem should be quite evident and that is to
archive
the "retired" components as flatpaks ( if the component is a desktop app )
or a as container ( if it's a server application or application stack )
This will require a ton of work from maintainers, which is funny as the
main reason this discussion has come up is because maintainers don't
have the time/bandwidth to, well, maintain things.
And to top it all off, won't really work for many/most packages, becasue
they are components, not self-contained/standalone applications.
Take my mailgraph example; how exactly is that supposed to work as a
standalone flatpak or container? It's a component of some larger system
rather than a standalone application useful in its own right.
(It requires access to /var/log/mail, maintains its own data store via
rrdtool, and generates files intended to be served via an external http
process)
Yes, mailgraph could be suitably munged to work within flatpak/container
scope restrictions, but if there was maintainer bandwidth to do that, it
wouldn't have been retired in the first place.
Meanwhile, what about retired libraries? How exactly is a flatpack or
container going to help folks continue to use them?
By the time you devise a way to bundle up all of these retired packages
in a way that they remain useful to all possible use-cases... you'll end
up with this meta-container thing of disparate, optionally-installable
software that's sorta configured to generally work together. I know, we
can call this thing "An Older Fedora Linux Distribution"
- Solomon
--
Solomon Peachy pizza at shaftnet dot org (email&xmpp)
@pizza:shaftnet dot org (matrix)
High Springs, FL speachy (freenode)