3

For whatever reasons, root-capable administrators at our organization limit the choice of packages to the vendor's official "base" repository (RHEL).

Not even EPEL is possible, much less IUS.

Our own -- hand-made -- RPMs are permissible, but still require filling out tickets and waiting. This not only makes installing them unnecessarily painful, but also impedes package-development -- I can't test my new RPM immediately.

However, we are allowed to build and install any software we wish -- as long as it goes into "our" directory. We've been building and installing such things for a while, and I'm wondering, if we can better organize such things so that, for example gcc-8.2 can be built on one system (with a prefix like /Data/local`) and installed on multiple others.

Of course, I can do that with plain tar-balls, but it would be nicer to have some sort of package-manager functionality such as, for example, to track dependencies...

Is there anything out there, or do we stick to the home-brewed tools?

Mikhail T.
  • 784

1 Answers1

1

You can try --prefix and --dbpath options. Not all RPMs will support --prefix, but if your rolling your own RPMs that won't be an issue, just make them relocatable.

I've been successful copying the systems rpm DB /tmp/lib/rpm to my own directory and specifying that via --dbpath. Then I can run rpm -i w/o root. Of course you now have a private copy of the DB and it will become out-of-date as your IT installs new packages - and other users won't know about your privately install packages. But hey, thats probably ok given the question you asked.

Unfortunately distributing your RPMs will still require other users to go thru IT or create their own DB as well, eg.

rpm -ivh --dpath ~/rpmdb --prefix ~/ mypkg-1.0-1.el8.x86_64.rpm

You could also ask your IT to make the system RPM DB writable.

brookbot
  • 131