On 06/23/2016 08:36 AM, Rich Megginson wrote: > 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? Another alternative is BYO Elasticsearch - CentOS _does not_ provide a distribution of Elasticsearch packages - instead, whoever wants to use ES will just have to install it from elastic.co > >> >>>> 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 > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > https://lists.centos.org/mailman/listinfo/centos-devel