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

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