[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