On Tue, Nov 10, 2015 at 12:57 PM, Mathieu Bridon <bochecha(a)daitauha.fr> wrote:
On Tue, 2015-11-10 at 12:08 -0600, Adam Miller wrote:
> Hello all,
> In the Fedora 24 timeframe the Fedora Release Engineering group
> is
> aiming to deliver the Layered Image Build Service[0] to allow Fedora
> contributors to build containers images. In the first iteration of
> this we're targeting Docker layered image support. Part of this will
> be to allow Fedora contributors to maintain Dockerfiles much like we
> maintain rpm spec files via DistGit.
>
> However we need to make a couple of decisions about naming
> conventions
> such that we can distinguish between rpms and container images as
> they
> are stored in Fedora DistGit. Also, alternatively we could setup a
> completely separate DistGit for container images that is disjoint
> from the one used for rpms. I would love feedback on everyone's
> preferences between those two options.
You could set it up in /srv/git/containers, in parallel to the current
/srv/git/rpms ?
That nicely avoids naming collisions.
It also should be quite asy now that dist-git is in ansible, you could
probably just factor out the path in the roles as a variable?
> Cockpit's Dockerfile repo in DistGit would be stored with a
> leading special character:
> fedpkg clone -cockpit
With the "-" as a leading character, you open yourself to nice errors
with the fact that it could be recognized as options. So you'd want to
type: fedpkg clone -- -cockpit
Yeah, all special characters have special oddities. Some of them we
have to consider from many targets and not just the shell so it's
probably not ideal.
Alternatively, if you separate the two distgits, you could have a
fedcontainer tool, which would just be fedpkg but with its
configuration pointing to the container distgit, the container build
service, etc...
Or maybe just a: fedpkg --container clone cockpit ?
Definitely something along these lines is what we'd want to do. I like
the idea. +1
Most of the code (at least the one handling dist-git) could probably be
reused without any difference.
Yes, it's likely something we'd want to maintain in the same code base
and have one just be a light wrapper of the other with the different
code paths as necessary.
All in all, separating them seems much simpler to me.
You'd have a bit of work up front (to adapt the Ansible playbooks and
fedpkg slightly), but you pretty much avoid a whole class of issues
with naming collisions, cli options, and future surprises.
Agreed.
+1
-AdamM