----- Original Message -----
> From: "Fabio Valentini" <decathorpe@xxxxxxxxx>
> To: "Development discussions related to Fedora" <devel@xxxxxxxxxxxxxxxxxxxxxxx>
> Sent: Friday, February 21, 2020 4:46:52 PM
> Subject: Re: Include non-RPM content in buildroot
>
> On Fri, Feb 21, 2020 at 3:58 PM Martin Sehnoutka <msehnout@xxxxxxxxxx> wrote:
> >
> > Hi,
>
> Hi!
>
> I think several of your assumptions are not necessarily correct, which
> might lead to wrong conclusions.
> My responses are inline below.
I second that ;).
>
> > before I write the proposal itself I just want to stress the fact that
> > it isn’t my intention to change the current packaging workflow and
> > definitely not the user experience. Also if you have C or Python
> > packages it would not affect your work at all (I’m not familiar with all
> > interpreted languages in Fedora, but I guess it is similar to Python and
> > therefore it is not affected by the problems I am going to describe).
>
> (snip)
>
> > First of all, let me describe the problem I see in our Fedora ecosystem
> > with relation to Go and Rust language ecosystems. More specifically in
> > the relation between RPM buildroot and packages in these ecosystems.
> > Both of these languages follow the idea that packages should be small
> > and only have a limited set of features. Developers then use a lot of
> > these packages to write the final executable that is meant for end-users
> > [1]. Also both of these languages use static linking of the final
> > binaries meaning that Fedora users don’t install RPM packages of these
> > libraries as they are already baked inside of the binary [2].
>
> One big difference between Go and Rust is that Go only namespaces
> libraries by their import path (with some exceptions, like gopkg.in),
> whereas Rust/cargo namespaces everything by name *and* version, which
> makes some things a lot easier. Then there's also the fact that a lot
> of Go libraries don't even *have* versions, and most only reference
> dependencies by "this git repository". There's some effort to make
> this better, but Go modules are not ready yet.
With Go modules("upstream ones") you are getting that name + version/tag(and rules what to use). Definitively many packages will not move to the modules/best practices, if that happen, we should try to move them to modules/best practices or move depending package to different package that is still maintained or in worst case scenario take over the maintenance -> fork.
>
> > The 1st problem is that if we want to build RPMs of the final
> > executables the way we do now, we need to package all these small
> > libraries into RPM even though they are just build dependencies and
> > users never install RPMs of these libraries. Many of these RPMs are
> > automatically generated from the upstream packages meaning that we don’t
> > do anything except for unpacking the upstream package (e.g. plain
> > tarball in case of crates.io) and then we package the same into RPM.
> > This process is unfortunately not fully automated and therefore requires
> > a certain amount of human effort.
> >
> >
> > To sum up the previous paragraph, I don’t think it is necessary to
> > repackage upstream tarball into a downstream RPM.
>
> Of course this requires a certain amount of human effort - because
> that's where the packager does their work. This includes:
>
> - verifying that the specified license is correct and suitable for
> (re)distribution in fedora
> - verify that the package builds and doesn't do crazy things
> - fix upstream and integration issues with patches
>
> And none of these three things is 100% automatable.
Seconding that.
>
> > The 2nd problem is present only in the Rust ecosystem (as far as my
> > knowledge goes). Cargo, the official package manager for Rust, can
> > handle the scenario where an executable depends on a single library in
> > two different versions [3]. Dnf, on the other hand, will not install two
> > versions of the same RPM package. What we do now is, that we patch the
> > affected executables and libraries to only use the newest versions
> > everywhere. This is again an additional maintenance cost and we create
> > differences from upstream, because these patches are not necessarily
> > merged. See this as an example:
> > https://src.fedoraproject.org/rpms/rust-bstr/blob/master/f/rust-bstr.spec#_17
> > https://github.com/BurntSushi/bstr/pull/23
(snip)
>
> > It is fair to say, that my first motivation was the current state of
> > packaging in RHEL but I’d prefer to discuss this in Fedora first.
> >
> >
> > The proposal itself is fairly simple: Let’s stop packaging all Go and
> > Rust libraries into RPM and install them to the buildroot in the
> > upstream format instead.
>
> As I said (and others have pointed out as well), this is not possible
> right now, primarily because automation cannot verify licensing and
> write and apply necessary patches without human intervention. And when
> you start curating your own Cargo registry, you might as well just
> package them as RPMs ... and the whole "use upstream format instead"
> probably won't work for Go unless you want to spin up fake github.com
> / bitbucket.com / gitlab.com servers for Go to download sources from.
>
I think you could spin up Go proxy with whitelisted packages(name/versions/tags/hashes) inside the Fedora's/Koji's network, but I think that with that we would be creating totally separate and different package build workflow to current dist-git and lookaside cache, that could work, but it would needed to be backed by lot of committed resources(people, HW,...).
> > The specific implementation is up for a discussion but I think it is
> > logical to start by asking what features do we want from the build
> > system? My answers are:
> >
> >
> > * We want to know what exactly was used to build the RPM to ensure
> > integrity. This is possible with upstream tarballs as well as with RPMs.
> > Just store a hash of the tarball.
> > * There should be no maintenance cost. If we would avoid modifying the
> > upstream package it would be the ideal case.
> > * It should be possible to patch the library in case of severe issues
> > like CVEs. This is a contradiction to the previous point, but it could
> > be solved by unpacking the upstream package into a git repository and
> > creating a new, modified package in upstream format from it.
>
> I'd argue that effectively maintaining a downstream fork is a bigger
> maintenance burden than building a normal RPM package with a patch
> file.
>
Effectively they are the same thing. IMHO maintaining "fork", i.e. Git repo with "Fedora" patches, is easier that just having some patch files laying around in dist git, thanks to the git cli tools(rebases and patch file generation for dist-git) and better discover-ability by outsiders(and automation possibilities,...), if present in public.
> > * It should be possible to run the build locally in exactly the same
> > way Koji does it. This is just about exposing our “registry” of packages
> > to the public Internet.
>
> That won't work for Go, as explained above (since go downloads sources
> based on import path, which is just a git repository somewhere).
>
It can, see Go proxy(just to illustrate, one of the possible implementations https://goproxy.io/).
> > Finally, the implementation could be something like this:
> > A service like release-monitoring could monitor the upstream projects
> > for new releases (e.g. NPM has a RSS feed). Every time there is a new
> > release it would automatically synchronize our own Fedora-specific
> > registry, which would in turn be accessible in buildroot. Then the RPM
> > macros like “cargo_build” could be modified to use this registry.
> > If we wanted to have the possibility to patch these libraries we could
> > synchronize the upstream release into our git repository and generate
> > packages in upstream format from it.
> >
> >
> > What do you think about the way we build RPM packages for Go and Rust?
> > Do you see other solutions or is it ok the way it is? (Please do not
> > suggest to “fix” the upstream communities)
>
> First, why not?
> Additionally, the Go project has for years been working on a module
> system that would make these things easier, and Rust/cargo already
> maps quite nicely onto RPM packaging ...
You have to always start with the upstream(however that might be hard and tedious, to build the relationships,...), if you don't, you will just end up swamped with "unupstreamable" patches and continuously slip in to the "I don't care" mode forcing the upstream to slip in to the "I don't care" mode too.
Overall I think that automating the packaging(including most/all of review) is the way to go so packagers don't need to really write any biolerplate(even cleaned up one), but that is really complex and still lots and lots of work away.
JC
>
> > Thanks for your opinions!
> > Martin
> >
> >
> > FAQ:
> > * Does it mean you want to get rid of -devel subpackages for C libraries?
> >
> > No. First of all C language does not have a single package manager and
> > it is still common to install dependencies using the distro specific
> > package manager. But packaging into RPM also comes with the advantage of
> > having shared libraries so in this case it has a positive effect on the
> > end-user experience. Rust and Go libraries on the other hand are mostly
> > useless for end-users.
>
> They might be useless for end users, but they still provide benefit
> for the distribution and packagers.
> Primarily, it provides a single "source of truth" for package dependencies.
> Secondarily, it provides a consistent way to run test suites for *all*
> libraries. When using "bundled" or "upstream" dependencies, the test
> suites for the *libraries* are never run. When you package them
> separately, the test suites are run for everything. This ensures
> quality, and lets packagers spot regressions and breakage sooner.
>
> > * I prefer to install development libraries using the distro package
> > manager instead of the upstream package manager. Why do you want to
> > change it?
> >
> > This is the case for C development, but it is different in most of the
> > modern languages. For example we ship Python packages, but we discourage
> > people from using them for their own development. Python developers are
> > instead encouraged to use pip to create a virtual environment and use
> > upstream packages. In the case of Rust, using the system libraries would
> > be much harder than using the upstream package manager.
>
> I don't know how others do this, but I exclusively develop and run my
> projects against the distro's python3 packages. That's where I expect
> my projects to run, so that's what I'm developing them against. I've
> never used pip or virtualenv to get dependencies.
>
> Fabio
>
> > * Does it mean you want to get rid of Rust packages like ripgrep.
> >
> > No. The end user experience stays unchanged. Packages that we ship to
> > Fedora users must be in RPM format, it is only the buildroot that changes.
> >
> > Notes:
> > [1] Please don’t discuss if it is a good idea or not. This is a
> > discussion for upstream of those languages.
> > [2] Again, please don’t discuss static vs. dynamic linking here.
> > [3] https://stephencoakley.com/2019/04/24/how-rust-solved-dependency-hell
> > _______________________________________________
> > 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
> _______________________________________________
> 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
>
_______________________________________________
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
