[Rpm-ecosystem] Containerization using rpm

Tomáš Smetana tomas at smetana.name
Thu May 14 18:16:10 UTC 2015


On Wed, 13 May 2015 12:22:51 -0400
Neil Horman <nhorman at tuxdriver.com> wrote:

> On Wed, May 13, 2015 at 05:34:56PM +0200, Jan Zelený wrote:
> > -- snip --
> > > One of the ways that I was looking at handling modified/removed files
> > > was to package changes at no less than directory granularity.  The idea
> > > would be that, for every changed file, the contents of the directory
> > > would be moved over to the customized rpm, and then, prior to executing
> > > an instance of the customized rpm, the copied directory (containing the
> > > modified file(s) would be bind mounted back to the origional location
> > > for that container instance. Its not as efficient as some solutions,
> > > but it fits in with the systemd-nspawn execution model nicely.
> > 
> > How about files in dirs like /usr/lib64?
> > 
> You're right, some directories this is really a non-optimal solution,
> because the directory and its subdirectories are huge.  My thought was that
> 'customization' of a container really was meant for modifying configuration
> files (like in /etc).  If you wanted to add/modify files in places
> like /usr/bin or /usr/lib64, then what you really need to do is package
> your custom application in its own rpm and then include it in the input
> manifest.

I'm afraid "proper" solution to the problem would require modifications of the
rpm itself.  I have briefly examined the rpm plugin interface to see whether
that could be a way to go but unfortunately no (it only provides several hooks
to the rpm transaction phases).  I'll keep looking into this...  There are
more use-cases beyond the container one that might benefit from having some
kind of file overrides in rpm.

Regards,
-- 
Tomáš Smetana


More information about the Rpm-ecosystem mailing list