On 06/23/2016 03:26 AM, Nico Kadel-Garcia wrote: > On Wed, Jun 22, 2016 at 3:11 PM, Matthias Runge > <mrunge at matthias-runge.de> wrote: >> On Tue, Jun 21, 2016 at 02:58:56PM -0600, Rich Megginson wrote: >>>> You end up with packages that other people have no idea the packages >>>> that are required to get a build or source code required to get the >>>> packages if packages are even used. >>>> >>>> If we can create a mechanism where others can reproduce this >>>> buildroot/area external to our koji instance and provide all the >>>> necessary documentation so it can also be easily reproduced by the >>>> community, then I could likely be convinced. >>> I think if we do that for CBS, it will have to be done that way, for exactly >>> the reasons you mention. Would you add that as a comment to the bug, or >>> would you mind if I did? https://bugs.centos.org/view.php?id=11073 >>> >> Yes, I would like a documented way to enable everyone to create >> comparable builds, but not necessarily bit-identical builds. For >> identical builds, one would have to make sure, the time, buildhost etc. >> are always the same. > This takes infrastructure to host and manage the various Maven built > dependencies, much like Python, modules from pypi.org and likeperl > modules from CPAN. I can warn you right now that this adds up to a lot > of work. JPackage used to try to do this, but the dependency trees got > out of hand and incompatible with built-in RHEL and thus CentOS or > Scientific Linux components very quickly. Even the packaginf of the > Sun published Java RPM's, for those who required the old Sun Java > specifically, became a licensing and incompatible packaging adventure. > >>>> What does Fedora do? >> Fedora forbids pre-built binary objects in their packages (with a very >> few exceptions). > As does RHEL, in general, RHEL core, yes, afaik. However, the Elasticsearch that Red Hat distributes with packages such as OpenShift is built with the Maven/MEAD process. > and as should CentOS. It's critical to open > source and free software distribution that the code, *including the > build tools*, be publicly available. Not all vendors have been good > about this, keeping some of the build tools as "secret sauce". I completely agree. Is there some way we could provide build artifacts, or whatever it is that parties outside of CBS will need to do their own maven builds, without providing a complete JPackage style repository? > >> For CentOS, we don't have that restriction. Please correct me, if I'm >> wrong. > Depends on the license of individual components. GPL tools with closed > source binary modules inserted in them after deployment are "tainted" > and cannot be republished as a whole package. That's why Nvidia and > similar modules "taint" the Linux kernel, and need to be published out > of band from the main kernel source. Similar restrictions may appy to > other projects: you'd have to carefully review *all* the licensing. > > It looks like CentOS policy has been to use open source and free > software builds, and avoid closed source binaries with their > potentially incompatible licensing. That kind of thing is why the Java > from Oracle is not, and cannot be, part of the base RHEL or in turn > the base CentOS operating systems. > >> Best, >> Matthias >> -- >> Matthias Runge <mrunge at matthias-runge.de> >> _______________________________________________ >> CentOS-devel mailing list >> CentOS-devel at centos.org >> https://lists.centos.org/mailman/listinfo/centos-devel > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > https://lists.centos.org/mailman/listinfo/centos-devel