[CentOS-devel] How to build maven packages in CBS?

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