On Thu, Jun 23, 2016 at 9:17 AM, Rich Megginson <rmeggins at redhat.com> wrote: > 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. > As the person who has to do that work. Run ... run now. Kill it with fire. Don't do it. >> 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 > > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > https://lists.centos.org/mailman/listinfo/centos-devel