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
~/.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 ...
With no really good ideas added since opening 1999.. is it still relevant.