The virt sig folks (and a large thanks to Lokesh here) have been keeping the docker packages quite fresh on cbs.centos.org. I'd like to begin publishing these via a virt-sig repo, tentatively called 'docker-current' or 'docker-latest'
My question is: We have a few other packages such as cockpit, that tie into docker, and are linked to atomic. What should be done with them?
My initial thinking would be to structure this a bit like SL does software collections. Docker would be a stand-alone repository that could then also be a part of a larger repo for atomic or other project.
Thoughts/opinions?
Hi,
On 15/10/14 10:10, Jim Perrin wrote:
The virt sig folks (and a large thanks to Lokesh here) have been keeping the docker packages quite fresh on cbs.centos.org. I'd like to begin publishing these via a virt-sig repo, tentatively called 'docker-current' or 'docker-latest'
My question is: We have a few other packages such as cockpit, that tie into docker, and are linked to atomic. What should be done with them?
My initial thinking would be to structure this a bit like SL does software collections. Docker would be a stand-alone repository that could then also be a part of a larger repo for atomic or other project.
Thoughts/opinions?
I will just comment about the technical side, as I have no strong opinion for the content of SIG repositories.
I think each repo content should be associated to a tag, and we should look at a procedure to transform a mash generated repo (mash dump all packages associated to a tag e.g /repos on cbs) to a production repository (location, signing, etc...).
In my view decoupling repository creation/koji too much, will make it hard to maintain on the long run.
We can have as many destination tags as we want and a package can be tagged multiple time, so the SIG can decide to depend on an external repository or to ship the packages in their own repo.
What do you think?
On 10/15/2014 02:47 PM, Thomas Oulevey wrote:
Hi,
On 15/10/14 10:10, Jim Perrin wrote:
The virt sig folks (and a large thanks to Lokesh here) have been keeping the docker packages quite fresh on cbs.centos.org. I'd like to begin publishing these via a virt-sig repo, tentatively called 'docker-current' or 'docker-latest'
My question is: We have a few other packages such as cockpit, that tie into docker, and are linked to atomic. What should be done with them?
My initial thinking would be to structure this a bit like SL does software collections. Docker would be a stand-alone repository that could then also be a part of a larger repo for atomic or other project.
Thoughts/opinions?
I will just comment about the technical side, as I have no strong opinion for the content of SIG repositories.
I think each repo content should be associated to a tag, and we should look at a procedure to transform a mash generated repo (mash dump all packages associated to a tag e.g /repos on cbs) to a production repository (location, signing, etc...).
Agreed. I was thinking about the user/consumer side, rather than production/creation.
In my view decoupling repository creation/koji too much, will make it hard to maintain on the long run.
We can have as many destination tags as we want and a package can be tagged multiple time, so the SIG can decide to depend on an external repository or to ship the packages in their own repo.
What do you think?
That works for me. Long-term we may need to look at package ownership/tracking for this. I'm not sure if we need something quite to the extent of fedora's pkgdb, or if it would allow groups(SIGs) to own the packages rather than individuals.
On 10/15/2014 04:10 PM, Jim Perrin wrote:
The virt sig folks (and a large thanks to Lokesh here) have been keeping the docker packages quite fresh on cbs.centos.org. I'd like to begin publishing these via a virt-sig repo, tentatively called 'docker-current' or 'docker-latest'
My question is: We have a few other packages such as cockpit, that tie into docker, and are linked to atomic. What should be done with them?
My initial thinking would be to structure this a bit like SL does software collections. Docker would be a stand-alone repository that could then also be a part of a larger repo for atomic or other project.
Thoughts/opinions?
if we do something like the Upstreams model we were talking about, that works quite nicely and should map to the tag's that Thomas brought up as well
On Wed, Oct 15, 2014, at 11:10 AM, Jim Perrin wrote:
My initial thinking would be to structure this a bit like SL does software collections. Docker would be a stand-alone repository that could then also be a part of a larger repo for atomic or other project.
I would like to have inheritance even just for Atomic, because of things like backported systemd - I'd like developers/compose boxes to be able to access one repository that doesn't pull in the newer systemd. Then the content repository includes that base plus the backported bits.
(It's not quite clean at the moment because ostree requires a newer glib2, but that's not as invasive as new systemd)
-
Colin Walters -
Jim Perrin -
Karanbir Singh -
Thomas Oulevey