On April 6, 2007 4:33:42 PM -0400 Michael Jennings <mej@xxxxxxxxx> wrote:
On Friday, 06 April 2007, at 10:54:09 (-0700),
Frank Cusack wrote:
Yep. There are lots of spec files that incorrectly (arguably) use
%_sysconfdir instead of just /etc. I'm sure someone just went
through and said "hey change all the /etc's to %_sysconfdir's just
for the heck of it! because we loves macros!)
We love macros because they are variable, not fixed. To do otherwise
is just silly.
Um, yes of course. *In general*.
Even if a particular package stupidly hard-codes /etc,
the correct solution is to redefine the macro (or define a new one),
not continue and compound the error by hardcoding more stuff.
Using %_sysconfdir, but defining it as some static value is misleading that
it is still configurable. I just don't see how defining a new macro (with a
constant value) or redefining %_sysconfdir (again, that must have a constant
value) has any value whatsoever.
IMHO, the "correct" solution is to go ahead and use %_sysconfdir
(ie, let the builder decide what he wants), and patch the software
to use it instead of hardcoded /etc. In a lot of cases though, that
can be pretty extensive.
In the vast majority of cases that I've seen, use of %_sysconfdir is
only broken because the documentation refers to /etc. There are just
a few cases (again, that I've seen) where (eg) %configure is used, and in
the %files manifest %_sysconfdir is used but the software ignores
--sysconfigdir (therefore %files should just have /etc). So my criticism
of overuse of %_sysconfdir is perhaps marginal.
BTW, some packages may not be "stupid" for hardcoding /etc. I can't think
of a specific case, but I can imagine an absolute requirement to use /etc.
RPM is, by and large, set up to work most seamlessly with GNU
autotools-based packages because that's what most FOSS uses. If /etc
is hard-coded into a spec file, it will most likely get converted to
%{_sysconfdir} because the hard-coding of /etc in the spec file is
more likely to be a mistake of an inexperienced packager than to be an
actual package requirement.
True.
-frank
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list
