Assume RPM_INSTALL_PREFIX0=/etc and RPM_INSTALL_PREFIX1=/usr . If we'd introduce exactly the same filesystem layout for configuration files in ~/, $RPM_INSTALL_PREFIX0 and $RPM_INSTALL_PREFIX1/lib/rpm, we would get a reasonably simplified implementation and usage. The second advantage may arise, if we introduce an environment variable RPM_PATH with exactly the same syntax and semantics, that we are used to from all other instances of class ``PATH''. And this last feature would now make it really possible to make the rpm package itself relocatable without such an ugly shell script wrapper, which is yet needed. In detail [the defaults, which most closely reflect the present situation]: RPM_PATH=~/rpm:/etc/rpm:/usr/lib/rpm ~/.rpmrc --> ~/rpm/rc ~/.rpmmacros --> ~/rpm/macros ~/.rpmpopt --> ~/rpm/popt /etc/rpmrc --> /etc/rpm/rc /etc/rpmmacros --> /etc/rpm/macros /etc/rpmpopt --> /etc/rpm/popt /usr/lib/rpm/rpmrc --> /usr/lib/rpm/rc /usr/lib/rpm/macros --> /usr/lib/rpm/macros /usr/lib/rpm/rpmpopt --> /usr/lib/rpm/popt This solution would also make it possible to reuse all the existing classes for path handling on the user's and the programmer's side. /*I assume, there already exist [probably several] classes, which implement searching for files on basis of value of a PATH object. And I certainly know, that such [sub-]classes exist for environment.Path [, because I have written one] on the user side.*/
(I apologize for the long delay in responding.) I think this is a good idea. Unfortunately, I cannot implement because of the legacy rpm configuration issues *unless* there is a good reason. So, assuming that this were implemented, what sort of functionality could then be added to rpm with a classifier? Any/all ideas welcome ...
Changing component
With no really good ideas added since opening 1999.. is it still relevant.