Re: rpm redirector wrapper

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

 



Doesn't seem like what RPM was designed to do. However, if a package is properly "relocatable", you should be able to use the:

--relocate OLDPATH=NEWPATH functionality. (See the man page or other rpm help for information.) There may be a way to force that for package that are not built as locatable.

Just on note from someone who has built a ton of packages. A _LOT_ of things like to hard code "/usr/bin", or "/usr/lib" or /usr/share/foo, etc internally. This can very much be hidden, and lead to some "interesting" problems. Just keep that in mind as you work on this.

--Mark

Chuck Vose wrote:
I want to write a wrapper for RPM and dpkg that looks at a config file
and interrupts / redirects the installer to put files in the correct
places in accordance with the local admin's preferences.


using XML to illustrate:

<default>
	<lib>/usr/lib</lib>
	<bin>/usr/bin</bin>
	<sbin>... etc ...

This would help in several ways:
a) With a completely compliant RPM (or whatever), the developer making
the installer would merely specify that each file is a binary, or a
shared library, etc. b) Alternatively, with an RPM that isn't specified this way, the wrapper
could easily parse out which files are which leading to no change
whatsoever for developers. The wrapper could choose where to put a file
based on what type of file it is (using the file package's tools), or
where it's being installed to, ie: things that RPM wants to install to
/usr/bin should be redirected to wherever the conf file says binaries
live. c) total cross distro goodness. If you've ever run slackware you
understand how annoying it is to copy all the includes to a differant
place to the other slack programs can see it.


One consideration is what to do with binaries that don't live in the
path. To which I see two easy responses:
a) wrapper makes lots of symlinks. I see no reason why /usr/bin
shouldn't be filled entirely with symlinks to
/usr/packages/fictional_distro_name/ or whatever the newest distro
chooses. Or why packages can't be separated by distro, or whatever the
local admin wants. b) an addition to my configuration file ala ld.so.conf. Non-standard
(according to the defaults) files are also specified:


<program name="mysql">
	<bin>/usr/local/bin</bin>
	...etc

I think that in order to make this work a utility like ldconfig would
have to be made to edit the path for users. Having a path that's 250
directories long might mess things up though.


I'm sure there are exceptions that would need to be considered, and
that's why I appeal to the list for advice in this subject.


Thank you in advance,
Chuck Vose


_______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list




_______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/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