On 06/23/2016 08:29 AM, Troy Dawson wrote:
On Thu, Jun 23, 2016 at 9:17 AM, Rich Megginson rmeggins@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@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@matthias-runge.de _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel