On 06/23/2016 08:29 AM, Troy Dawson wrote: > 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. So - what is the alternative? That we have to maintain 300+ rpms, some of which may have conflicting dependencies? Wait for CuCoS? > >>> 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 > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > https://lists.centos.org/mailman/listinfo/centos-devel