On May 25, 2011, at 2:25 PM, Per Øyvind Karlsen wrote:
> When adding macros/mandriva in the past, I tried adding %{load:
> /etc/rpm/macros.d/*.macros}
> to it for loading macros rather than specifying it during ./configure,
> but I quickly discovered that support for wildcards wasn't supported and
> didn't
> care much about it since, figguring that I'd look into implementing it
> sometime
> later.
>
Yes. Deliberately limited to single level of loading (i.e. you vcan't
have %load:...} do additional %{load:...}.
Deliberately minimalistic and KISS sane because what I see with
Mandriva macros is a frigging mess.
Hint: the %{load:...} is in need of refactoring so that, say, if
you install perl-devel, then you also install *WHATEVER PERL PROGRAMMERS WISH*
isntead of this isnsanity of
RPM supports every possible means of automating macros and building.
The pre-requisites on rpm-build are _ALREAD_ impossibly hard to meet
for the tool that MUST be in place and reliable before any other tool
can be built from *.src.rpm.
The "bloat" is so frigging bad that I'm considering radical actions
like just dumping rpmbuild to lose _ALL_ of the borkage and macro madness
going "forward".
> I guess that the mandriva macros probably served as inspiration for
> adding this to the other vendor macros recently checked in as well,
> so as I take blame for this, I might as well implement the actual support
> for this at the same time.
>
Yes: mandriva.in is *definietly* the right thing to do, and *is ebing
used as a model for other vendor's.
You most definitely got manriva.in right. And then set about burying all
sorts of macros in all sorts of place for "compatibility", and adding
rubygems and cmake and whatever else, when for "feature parity"
rpmbuild is almost certyainly going to have to pick up the crappy
refactoring inmplemented @rpm.org that is _ALREADY_ showing flaws within
the past 7 days (see magic_and_file breakage check-ins)
> I dunno if there's any specific reason for why this wasn't implemented
> earlier..?
>
It *was* implemented earlier, several times.
First there was CPU-OS (what ewt and I preferred) vs CPU-VENDOR-OS
(what the build mommas instantly started screaming for). That was done in 1999.
Then there was adding a per-vendor stage to what was originally
default -> per-system -> per-user -> per-specfile
overloading. And just like CPU-VENDOR-OS/macros done in 1999,
every vendor _TOTALLY_ ignored and just patched RPM.
<fast forward>
You get *ONE* file -- macros.d/mandriva.in, and it gets installed in *ONE*
place: /usr/lib/rpm/macros.d/VENDOR.in and all the rest is going to be
ripped out and discarded.
Instead (like above) its all just
Hey: why not globs! and *RE's! and create Yet Another Hierarchy!
and go make some teensy little pee puddles and say
Ship it!
which is what has been happening for *12 YEARS NOW* in spite of continuos
and coherent suggestions NOT to keep mucking about with Newer! Better! Bestest!
that isn't newer, is worse, and not at all the best hierarchical design.
Hint: there's macro contexts that have been waiting to be deployed
in the RPM API since February 1998 when *I* implemented. At this
point I *know* what SHOULD be done and am on a path to do what *I*,
not vendor's and FL/OSS, want, because that is in *my* interest.
73 de Jeff
> If there's none, the usefulness of adding support for this is rather obvious
> and
> if noone objects, I'll commit the following patch. :)
>
> --
> Regards,
> Per Øyvind
> <rpm-5.3.11-glob-wildcards-for-loading-macro-files.patch>
smime.p7s
Description: S/MIME cryptographic signature
