Bug 6881 - Proposal: adopt same file structure for ``macros'', ``rc'' and ``popt'' in ~/.rpm/, /etc/rpm/ and /usr/lib/rpm/.
Proposal: adopt same file structure for ``macros'', ``rc'' and ``popt'' in ~/...
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: rpm-build (Show other bugs)
6.1
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-11-10 11:37 EST by mp
Modified: 2007-04-18 12:24 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-02-10 14:19:25 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description mp 1999-11-10 11:37:34 EST
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.*/
Comment 1 Jeff Johnson 1999-12-15 12:55:59 EST
(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 ...
Comment 2 Jeff Johnson 2001-02-21 14:35:43 EST
Changing component
Comment 3 Stephen John Smoogen 2003-01-23 17:55:10 EST
With no really good ideas added since opening 1999.. is it still relevant.

Note You need to log in before you can comment on or make changes to this bug.