On 9/13/18 3:04 PM, Brian Reichert wrote:
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...
In my opinion this should not be placed into rpm as it is easily setup
by the user.
ROOTPATH=BUILDROOT/mnt/chroot/tomcat
install -vdm 755 ${ROOTPATH}
LIST=all required "base" rpms
for i in ${LIST}; do
rpm --upgrade --nodeps --noscripts --root ${ROOTPATH} --dbpath
${DBPATH} ${REPOPATH}/${i}-[0-9]*-*.*.rpm
done
Wrap this up in an rpm spec file and you are good to go
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxxxxx
http://lists.rpm.org/mailman/listinfo/rpm-list
