Dne 08. 01. 22 v 1:08 Fabio Valentini napsal(a):
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.)
I did not programmed much in Rust so I can't tell. :)
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).
Another example is chezmoi:
https://github.com/twpayne/chezmoi/blob/master/go.mod#L5
Not packaged in Fedora at all. However, a great tool for solving your
dotfiles.
Upstream recommended way how to install this -> curl install script to
bash... :(
However, they also have RPM files (without repository).
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.
I really can't blame the people. Not everyone has the week of time to
package all the dependencies
one by one. But COPR is a nice shortcut to that so I can have what the
upstream is producing
without spending so much time and just re-using binaries produced
upstream. The same works for
pinging people to update their packages.
[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.
+1 we need some other solution to that. However, I still think that it
should
be distro agnostic, otherwise authors won't care.
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.
I like this on Flatpaks. You can take Flatpaks from Flathub or Fedora
Flatpak repository. For the
second one Fedora is making sure that you are getting the updates again
but user is not
forced to use only the Fedora ones.
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.
Don't have to be sorry. These inputs are exactly what I'm looking for.
Also your frustration is showing the point here.
Best Regards,
Jirka
_______________________________________________
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
