[CentOS-devel] How to build maven packages in CBS?
Rich Megginson
rmeggins at redhat.com
Thu Jun 23 14:59:00 UTC 2016
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
More information about the CentOS-devel
mailing list