Should've sent this earlier, but better late than never.
At the last virt SIG meeting we were looking at good places to keep packages like cockpit, which I'm not sure belongs in a particular SIG yet.
Also, it was mentioned that we could make SIG repos depend on each other, and IIUC, KB has an example (in theory atleast) demonstrating that.
Over to you KB..
On 06/14/2015 09:29 PM, Lokesh Mandvekar wrote:
At the last virt SIG meeting we were looking at good places to keep packages like cockpit, which I'm not sure belongs in a particular SIG yet.
Might make sense in Atomic, AIUI we want to carry some of the RPMs in the main build and then just pull down the Cockpit container to run Cockpit...?
Best,
jzb
On 15/06/15 02:29, Lokesh Mandvekar wrote:
Should've sent this earlier, but better late than never.
At the last virt SIG meeting we were looking at good places to keep packages like cockpit, which I'm not sure belongs in a particular SIG yet.
I believe there is a cockpit build in the CentOS Atomic Host repos now, so maybe Atomic SIG might be the best place to park this at for now.
the other way of looking at this might be: who's the target user base, and within that which SIG delivers the most relevant content. Put stuff closest to them.
Also, it was mentioned that we could make SIG repos depend on each other, and IIUC, KB has an example (in theory atleast) demonstrating that.
Over to you KB..
Atomic SIG pulls from the Virt SIG packages, but neither are in a released state, so there is no hard dependency in place there as yet.
On 16/06/15 12:28, Karanbir Singh wrote:
On 15/06/15 02:29, Lokesh Mandvekar wrote:
Should've sent this earlier, but better late than never.
At the last virt SIG meeting we were looking at good places to keep packages like cockpit, which I'm not sure belongs in a particular SIG yet.
I believe there is a cockpit build in the CentOS Atomic Host repos now, so maybe Atomic SIG might be the best place to park this at for now.
the other way of looking at this might be: who's the target user base, and within that which SIG delivers the most relevant content. Put stuff closest to them.
Also, it was mentioned that we could make SIG repos depend on each other, and IIUC, KB has an example (in theory atleast) demonstrating that.
Over to you KB..
Atomic SIG pulls from the Virt SIG packages, but neither are in a released state, so there is no hard dependency in place there as yet.
expanding on this, once content is 'released' the corrosponding centos-release-<sig>-component.rpm can have a requires: for the dependancy repo via a requires: centos-release-<other sig>-component
handling this at the rpm level makes it simplistic to manage with existing tooling as well.
-
Joe Brockmeier -
Karanbir Singh -
Lokesh Mandvekar