Are there any instructions/examples about how to use `cbs maven-build/maven-chain`?
On 06/20/2016 04:41 PM, Mikolaj Izdebski wrote:
On 06/20/2016 11:33 PM, Rich Megginson wrote:
Are there any instructions/examples about how to use `cbs maven-build/maven-chain`?
Maven support is not enabled in CentOS CBS, AFAIK.
Correct .. although there is an SCL version of maven out there. No idea how it works in cbs though.
On 06/20/2016 11:54 PM, Johnny Hughes wrote:
On 06/20/2016 04:41 PM, Mikolaj Izdebski wrote:
On 06/20/2016 11:33 PM, Rich Megginson wrote:
Are there any instructions/examples about how to use `cbs maven-build/maven-chain`?
Maven support is not enabled in CentOS CBS, AFAIK.
Correct .. although there is an SCL version of maven out there. No idea how it works in cbs though.
Maven in SCL (maven30, rh-maven33) is packaged as traditional RPMs. These packages are built the same way as any ordinary CentOS or SCL package (with build/chain-build).
On 06/20/2016 04:13 PM, Mikolaj Izdebski wrote:
On 06/20/2016 11:54 PM, Johnny Hughes wrote:
On 06/20/2016 04:41 PM, Mikolaj Izdebski wrote:
On 06/20/2016 11:33 PM, Rich Megginson wrote:
Are there any instructions/examples about how to use `cbs maven-build/maven-chain`?
Maven support is not enabled in CentOS CBS, AFAIK.
Correct .. although there is an SCL version of maven out there. No idea how it works in cbs though.
Maven in SCL (maven30, rh-maven33) is packaged as traditional RPMs. These packages are built the same way as any ordinary CentOS or SCL package (with build/chain-build).
https://bugs.centos.org/view.php?id=11073 support maven builds
On 06/20/2016 06:35 PM, Rich Megginson wrote:
On 06/20/2016 04:13 PM, Mikolaj Izdebski wrote:
On 06/20/2016 11:54 PM, Johnny Hughes wrote:
On 06/20/2016 04:41 PM, Mikolaj Izdebski wrote:
On 06/20/2016 11:33 PM, Rich Megginson wrote:
Are there any instructions/examples about how to use `cbs maven-build/maven-chain`?
Maven support is not enabled in CentOS CBS, AFAIK.
Correct .. although there is an SCL version of maven out there. No idea how it works in cbs though.
Maven in SCL (maven30, rh-maven33) is packaged as traditional RPMs. These packages are built the same way as any ordinary CentOS or SCL package (with build/chain-build).
https://bugs.centos.org/view.php?id=11073 support maven builds
I'll let others discuss this here, but I don't like doing it that way because it makes it very hard to reproduce outside CBS.
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.
IMHO, one of the most important things we do as a community distribution is produce the ability to do these things for the community as well.
But, I am sure I can be convinced this is a good idea.
What does Fedora do?
On 06/21/2016 02:21 PM, Johnny Hughes wrote:
What does Fedora do?
Koji Maven integration (aka MEAD) is not used in Fedora.
In Fedora (and also CentOS 7, SCL) packages are built in offline mode. Maven remote repositories, such as Maven Central, are not used at all. All build dependencies (including project dependencies, Maven plugins or test dependencies) must be packaged as RPMs.
Packaging documentation can be found in javapackages-tools-doc (Fedora, CentOS 7), rh-java-common-javapackages-tools-doc (SCL) or online at [1].
[1] https://fedorahosted.org/released/javapackages/doc/
On 06/21/2016 06:21 AM, Johnny Hughes wrote:
On 06/20/2016 06:35 PM, Rich Megginson wrote:
On 06/20/2016 04:13 PM, Mikolaj Izdebski wrote:
On 06/20/2016 11:54 PM, Johnny Hughes wrote:
On 06/20/2016 04:41 PM, Mikolaj Izdebski wrote:
On 06/20/2016 11:33 PM, Rich Megginson wrote:
Are there any instructions/examples about how to use `cbs maven-build/maven-chain`?
Maven support is not enabled in CentOS CBS, AFAIK.
Correct .. although there is an SCL version of maven out there. No idea how it works in cbs though.
Maven in SCL (maven30, rh-maven33) is packaged as traditional RPMs. These packages are built the same way as any ordinary CentOS or SCL package (with build/chain-build).
https://bugs.centos.org/view.php?id=11073 support maven builds
I'll let others discuss this here, but I don't like doing it that way because it makes it very hard to reproduce outside CBS.
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
IMHO, one of the most important things we do as a community distribution is produce the ability to do these things for the community as well.
But, I am sure I can be convinced this is a good idea.
What does Fedora do?
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
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.
What does Fedora do?
Fedora forbids pre-built binary objects in their packages (with a very few exceptions).
For CentOS, we don't have that restriction. Please correct me, if I'm wrong.
Best, Matthias
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, 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".
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
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.
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
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.
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
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
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@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?
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@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
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On 23/06/16 16:29, Troy Dawson wrote:
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.
Members of the SIG will do it. The discussion is about enabling a technology, not about forcing anyone to use it.
Matthias
On 22/06/16 20:11, Matthias Runge wrote:
What does Fedora do?
Fedora forbids pre-built binary objects in their packages (with a very few exceptions).
For CentOS, we don't have that restriction. Please correct me, if I'm wrong.
That is right, we dont enforce from source builds, but we do need the content to be open source ideally, or you to have demonstrate-able rights to redistribute unconditionally, any content imported via that route.
What would this reproduceable builds chain look like if we were to start looking at Maven/MEAD ? Also, how would we verify the content that goes through ?
Also, is this literally just a case of doing a bootstrap or is the intention to stay with that model longer term ?
regards,
On Thu, Jun 23, 2016 at 11:44 AM, Karanbir Singh mail-lists@karan.org wrote:
On 22/06/16 20:11, Matthias Runge wrote:
What does Fedora do?
Fedora forbids pre-built binary objects in their packages (with a very few exceptions).
For CentOS, we don't have that restriction. Please correct me, if I'm wrong.
That is right, we dont enforce from source builds, but we do need the content to be open source ideally, or you to have demonstrate-able rights to redistribute unconditionally, any content imported via that route.
What would this reproduceable builds chain look like if we were to start looking at Maven/MEAD ? Also, how would we verify the content that goes through ?
It's inherently unpredictable. While many of the standard Maven repository packages have good license, it's not a pre-requisite to provide buildable or open source or free software licenses for packages accepted by various public Maven repositories. The only way to prevent loading of an unexpectedly mislicensed package in doing a normal maven build is to turn off all public repositories and use a well defined local one. And makiong sure of *that* basically means turning off DNS or all networking in your build environment.
See http://stackoverflow.com/questions/2493507/maven-report-on-licenses-your-pro... for some notes on publishing license dependencies, but remember that Maven suffers from some of the same issues of CPAN and PyPI. The package you build on Tuesday may not match the package, and all the dependencies, of a package you build on Thursday unless you go to incredible amounts of work to lock down *all* the dependencies. And the one you fail to lock down may develop a conflict with the one you *do* lock down.
It's one of my pet peeves about the "just install it from scratch" approach to software deployment. It's also why I spend so much time writing RPM's for internal projects, so we do have well defined modules.
On 25/06/16 04:28, Nico Kadel-Garcia wrote:
It's inherently unpredictable. While many of the standard Maven repository packages have good license, it's not a pre-requisite to provide buildable or open source or free software licenses for packages accepted by various public Maven repositories. The only way to prevent loading of an unexpectedly mislicensed package in doing a normal maven build is to turn off all public repositories and use a well defined local one. And makiong sure of *that* basically means turning off DNS or all networking in your build environment.
Assuming someone has done the work to look at the licenses etc for the stack they pull through, how does koji itself handle the metadata around the content that went in - thats the key thing really, can we preserve that, export it in a way that its further consumeable down the line ? ie. can the buildroots be regenerated ?
regards
On Sat, Jun 25, 2016 at 5:28 AM, Nico Kadel-Garcia nkadel@gmail.com wrote:
What would this reproduceable builds chain look like if we were to start looking at Maven/MEAD ? Also, how would we verify the content that goes through ?
It's inherently unpredictable.
Unpredictable are pure Maven builds outside MEAD/Koji, MEAD enables reproducible builds by restricting access to the internal Maven repositories only. It is up to SIG policy how it will bootstrap this internal repo, if we do it all using koji maven-build from sources and do not import binary JARs, we'll have everything rebuildable from sources. Hard part is to resolve dependency chains and then build it in the right order.
Cheers, Alan
On 27/06/16 20:06, Alan Pevec wrote:
On Sat, Jun 25, 2016 at 5:28 AM, Nico Kadel-Garcia nkadel@gmail.com wrote:
What would this reproduceable builds chain look like if we were to start looking at Maven/MEAD ? Also, how would we verify the content that goes through ?
It's inherently unpredictable.
Unpredictable are pure Maven builds outside MEAD/Koji, MEAD enables reproducible builds by restricting access to the internal Maven repositories only. It is up to SIG policy how it will bootstrap this internal repo, if we do it all using koji maven-build from sources and do not import binary JARs, we'll have everything rebuildable from sources. Hard part is to resolve dependency chains and then build it in the right order.
Maybe this boils down to the question: how can someone rebuild a package OUTSIDE MEAD/Koji.
If we make sure, this is documented and reproducible, would it be acceptable then?
Matthias
-
Alan Pevec -
Johnny Hughes -
Karanbir Singh -
Matthias Runge -
Mikolaj Izdebski -
Nico Kadel-Garcia -
Rich Megginson -
Troy Dawson