On Fri, 21 Feb 2020 at 09:58, Martin Sehnoutka <msehnout@xxxxxxxxxx> wrote: > > Hi, > > 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). > > > 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]. > Ok here are some of the issues we have to deal with for these sorts of changes: 1. RPMs are built in Fedora without any access to the Internet. They do not and can not pull in anything outside of their chroot as they are building. This is a security requirement for multiple reasons where everytime we relax it.. bad things happen. [Seriously there are enough people with bad intentions to spoil everything for everyone multiple times.] 2. To deal with 1, you need to now set up local registry and local copies of the cargo/go/etc code and have mock learn how to 'dump' that into the chroot in a way that it can see. 3. We need to then have a copy of the code in the Fedora build area. That code will have had to have been vetted for license problems and all the other reviews we do for getting a package because you dont' want to have a cargo or any other thing with an rm -rf embedded in it. 4. We have now created 2-3 build systems which will need monitoring, reviews, equipment, and tooling: a. Ruby/perl/python build system (since they have the same issues). b. Go build system c. Rust build system d. RPM build system. e. Code repositories and registries for each of these so that the outer mock could do the right thing and put things into the chroot. 5. Deal with all the duct tape with all the other tools that are needed to get anything done. The fact that you have to add a lot for 2,3,4 and 5.. it has always been faster to just stick with doing everything in 1 and make RPMs. The tasks are not impossible ones, but they are not simple and they need someone to do that work. If you are going to back that proposal with a working prototype we can shove into production with all our other prototypes.. that will help a lot. -- Stephen J Smoogen. _______________________________________________ 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
