I think that my general idea is something a little more simplistic at this point in time. Basically I would like to 'diff' the system to figure out what has changed and what hasn't. I know there's a utility for this, I just have to dig around for a bit. Once I see what has changed I might be able to move the files around. Though now that I'm thinking about it I guess a lot of things are hard coded into the files aren't they? Do you suppose I'd have to make a makefile auto-patcher instead? I guess what I'm asking is, would it be better to start before the whole process, or afterward? I suppose both might work as well. I'll admit that what I'm thinking about at the moment is mostly for my pleasure, but who knows what talented developer will steal my idea and turn it into gold (certainly not me, I barely know Java). On Fri, 2004-04-02 at 14:00, Mark Hatle wrote: > 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 _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
