On Fri, Jan 7, 2022 at 9:48 PM Jiri Konecny <jkonecny@xxxxxxxxxx> wrote: > > Hi everyone, > > I would like to do here a bit of brainstorming and ask if there is an > existing solution to this problem. To explain my problem, > recently I found more and more apps likes terminals, prompt and command > line tooling, which are great to use but not > packaged or are outdated in our repositories. The reason for this is > simple. These apps are written in languages like Rust or > Go which works the way that there are plenty of smaller libraries and > these are really a hell to package or maintain in > Fedora. On the other hand it's pretty simple to build it from the source > (most of the time) but hard to split it into packages. Hello! (I'd argue that most popular Rust libraries really are not small at all. Some are, but some are large. Most are medium-sized, as Rust does not have the same incentives as, for example, NodeJS, to publish single-function-modules.) > Great example of this is Startship command line prompt, we have outdated > version but when you look to dependencies[1] > you have to completely understand. There is a slight problem with picking starship as an example here. Because it is almost certainly the Rust application with the largest number of (direct) dependencies. The starship project also frequently adds new dependencies with new versions, and aggressively uses new major versions of dependencies, both of which make updating it very painful (which is also why the package maintainer seemingly gave up on the Fedora package and now only updates it in COPR). > I don't want to start here a discussion if that is insecure or a good > idea. That is something which has to be solved by > people creating the ecosystem around these languages. What I would like > to discuss here is how Fedora could improve > the situation. Where you see a technological problem, I see a deeper problem with the way we do package maintenance. Many packagers came to the Rust ecosystem because they wanted to add "that one cool new application" to Fedora. But they usually don't have the time to care about their dependencies too, other than maybe doing the initial packaging and then throwing them over the rust-sig wall. On the other hand, there's people like me, who try to keep the lower-level libraries up-to-date, monitor security advisories, etc., but obviously I can't care about updating shiny application X or the-new-hotness Y as well - because I just don't have the time. And I don't think making sure somebody else can update their package is my responsibility. That disconnect between "application maintainers" and "library maintainers" is often frustrating. Application maintainers grumble about having to file new package review tickets, and that their dependencies are out of date. Library maintainers often update libraries to new major versions only "as needed", because those major changes often involve creating compat packages or pushing coordinated updates of all dependents of a library. But often the "I can't update my shiny application X to the new version! The libraries are out of date, you lazy library maintainers!" (I'm exaggarating, but you get the point) is the result of missing "major" updates that just weren't needed (or possible!) before shiny application X needed the new version. Additionally, some application maintainers are now no longer actively maintaining their Fedora packages, but instead push updates only to COPR, where they don't need to follow Packaging Guidelines. starship is an example here [1]. While the COPR is up-to-date (with using bundled dependencies), the Fedora package could be described as unmaintained. [1]: https://copr.fedorainfracloud.org/coprs/atim/starship/ > I would say, that for GUI apps we already done that. We have Flatpak > which is doing great job to get these apps there > and motivate people to do that because it's then consumable on plenty of > places. However, this is not really usable if you > need app which is core part of the system (like prompt) or emacs/vim > which needs a lot of dependencies from the system > based on user configuration. > > My question is, what we can do to avoid situations as in Windows? I mean > that first thing what Win users are doing is to > look on internet and start to download random binaries. Do we have > something like Flatpaks for core parts of the system > now? Is there something we could adopt? Am I completely wrong with my > assumptions :D? > > Also want to mention that I don't have much experience with this. It's > more that I'm worried and maybe this discussion > could lead to something in the future. The problem I see with "containerizing" CLI applications is that those often require system access, and cannot be sandboxed or containerized at all. Another problem is that while *some* Rust applications can very easily be installed with "cargo install foo", some cannot. Fedora packages for library dependencies provide additional support for building things, like making sure system libraries are pulled in as needed, making sure that bindings are built against system libraries instead of bundled dependencies (or pre-built binaries .... ....), using correct compilation flags, making sure crates have an acceptable License, or have the necessary patches applied to build on Fedora, etc. And additionally, using a Fedora package, you automatically get (security) updates for your applications, which is something most other shiny new tools (like "go get" or "cargo install") just do not support at all. So, putting things into a flatpak or snap could work around *some* of the problems you're seeing, but it makes some problems much much worse - for example, we have very high standards for package quality and legal compliance in Fedora, and we also make sure to build things to link against system libraries, etc. By throwing all that out and using some flatpak or snap build process for your CLI app, you lose those things, potentially producing *worse* (or broken) application binaries, or even opening yourself up to legal problems, in some cases. I'm sorry if I rambled too much, but I have a lot of frustration and thoughts regarding this problem. Fabio _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
