conventions for delivering a chrooted environment via an RPM?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello, I'm new to this list.  I've tried to search this list's
archives, and other places on the net on this topic, but I'm having
a hard time coming up with the right keywords to direct me.

I was wondering if there are any suggested conventions for delivering
a chrooted environment via an RPM.

I don't mean using '--root' to fake an RPM installation into a
different directory.  I mean using an RPM to deliver a payload that
will run in a chrooted environment.

E.g. a hypothetical 'tomcat-chroot' RPM is authored.  When this RPM
is installed alongside of others, there will be a '/home/tomcat'
folder, containing a sufficiently-populated chroot environment,
etc, with a mounted procfs, etc.

Obviously, I could just write an all-powerful %post script that does
all of the manual work, but I wanted the RPM database to reflect
the resulting files are owned by the 'tomcat-chroot' RPM.

That in turn implies the RPM's payload is fully-populated at the
'rpmbuild' stage.

That's the step that could be handled in any number of different
ways, and I was wondering if there have been any evolved mechanisms
at this point to handle that gracefully.

I know there are any number of container technologies that are far
more graceful about this, but at $WORK, I'm still stuck with an
RPM-managed set of systems...

-- 
Brian Reichert				<reichert@xxxxxxxxxxx>
BSD admin/developer at large	
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxxxxx
http://lists.rpm.org/mailman/listinfo/rpm-list



[Index of Archives]     [RPM Ecosystem]     [Linux Kernel]     [Red Hat Install]     [PAM]     [Red Hat Watch]     [Red Hat Development]     [Red Hat]     [Gimp]     [Yosemite News]     [IETF Discussion]

  Powered by Linux