On 9/24/26 5:52 AM, Cristian Le via devel wrote:
I can understand that some packagers veiwpoint of just wanting to get
something out the door and have the package done and ready to use. But
what about the maintenance? I would appreciate if proposals such as
these come with receipts of the experience in the maintenance and
having gone through all of the ways things are going wrong. E.g. the
openssl4 transition was not fun for the rust packages that were
vendoring. Or even the day-to-day maintenance experience after going
through the hurdle of getting a whole rust dependency tree to work,
which I do not find that daunting (mostly due to help of everyone's
collaboration).
"Almost all problems start as a solution to other, previous problems"
Specifically, vendoring/bundling has a huge practical appeal as a
solution to the immediate issues, but it tends to cause trouble down the
road.
It seems to me that vendoring in RPMs is really a compromise sitting
between the actual alternative approaches:
* use isolated flatpak packages that just carry whatever they need
with them,
* or persist in trying to create a consistent distribution using
distro-approved libraries.
I personally still prefer the integrated distro approach, but I am
beginning to think that the isolated app approach (Silverblue) might end
up taking over: an immutable host system that enforces sharing core,
security-sensitive libraries, while allowing app-specific module
vendoring in flatpaks. After all, it's similar to what Android is doing,
In any case, vendoring in RPM packages may be picking the bad parts from
both of those approaches: it has both version explosion, lack of
transparency/consistent patching, and no package isolation. *I wonder if
it would make sense to require that if an RPM has to vendor something
significant, it should become a flatpak. *Of course that brings the
question what is a significant component---it shouldn't matter if an app
is having its own version of say getopts(), as opposed to say libssl.
Also, there are issues with flatpak app integration outside of desktop
environment (pipes/environment variables/aliases/signals/filesystem
namespace)....
--
_______________________________________________
devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/[email protected]
Do not reply to spam, report it:
https://forge.fedoraproject.org/infra/tickets/issues/new
