[Rpm-ecosystem] Containerization using rpm

[Neil Horman]

On Thu, May 14, 2015 at 08:16:10PM +0200, Tomáš Smetana wrote:
> 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,

So, sort of (at least I think sort of).  Ostensibly the files which you would
want to customize within an rpm are going to be configuration files, which
properly written rpms will tag as %conf, meaning the rpm database will record
the initial checksum of the file, but understands that it might change.  If
there are files which you want to modify that are not %conf files (i.e. new
binaries to add/delete/change), my argument is that in the case of additions,
you need to pacakge your new files up in their own rpm, and add them to a
repository that you specify in your manifest, so that they can be installed
along with the other rpms that make up your container (keeping the rpm database
consistent with the filesystem.  In the case of binary modification or removal,
I think that goes somewhat counter to what rpm does.  I'm not saying theres not
a need to do it, but I'm not sure I see the use case in modifing a non
configuration binary file outside an rpm install path.  Yes, it may be quicker
and dirtier to do so, but the packaging rigor that rpm offers is intended to be
an advantage in consistency here.

Neil

> -- 
> Tomáš Smetana
>