On Thu, Nov 12, 2015 at 03:01:49PM -0500, Ray Strode wrote:
On Tue, Nov 10, 2015 at 1:08 PM, Adam Miller
> If we were to go with the former rather than the latter, we would need
> to find a way to "namespace" container images so they can be
> determined as different. I've thought about this a lot and I worry
> about defining a namespace by some alphanumberic sequence because I
> just know that at some point there will end up being a piece of
> software in the ecosystem that we want to package as a rpm that will
> share this pattern and result in problematic filtering. We could
> accept that risk and simply say "this sequence is a reserved word" or
> use a special character as the leading character in a DistGit
> repository name to signify that it is a container.
git repositories normally use '/' to separate namespaces, so i'd propose
$ fedpkg clone containers/cockpit
and maybe add support for
$ fedpkg clone srpms/cockpit
at the same time.
This has the added benefit that cgit will automatically filter docker
reposistories when you visit, e.g,
I like this too. Here are three thoughts:
Perhaps, we use 'dockerfiles' for the prefix instead of 'containers',
because presumably there will be some whole new way to build
containers in 2017, and we'll need to keep our dockerfiles/ repos
separate from our awesomefiles/ repos.
We could also use this opportunity to move the kickstarts (another
input to koji builds) away from https://fedorahosted.org/spin-kickstarts
and over to dist-git as well, with a namespace like 'kickstarts/kde'
The existing rpm content could be moved to a 'specfiles/' namespace
(or maybe 'srpms/'?) but we could further add some apache httpd rules that
respond with a redirect to the 'srpms/' namespace if the requests to
the base namespaceless-namespace level are met with a 404. -- "when in
doubt, default to srpms/". That might help keep some of our existing
tools working as-is without too much catastrophe.