On May 25, 2011, at 3:53 PM, Jeff Johnson wrote:
>
> 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.
>>
>
> SHow me _ANY_ distro using %{load:...} in a _RELEASE_
> and I'l consider extending to globs.
>
> ATM, %{load:...} was implemented like 3+ years ago and
> there is literally _NO_ usage I'm aware of.
>
> I'll consider removing the *DELIBERATELY IMPLEMENTED RESTRICTIONS*
> to %{load:...} if/when I see an actual need or usage case _ANYWHERE_.
>
And let me try to indicate what is WRONG with
%{load:/etc/rpm/macros.d/*.macros}
When a build breaks you haven't ANY clue why the build broke
because there is NO indication of what SHOULD be in /etc/rpm,
particularly when vendors (like Mandriva and Fedorable) have
chosen to distribute the wee widdle warez in per-system,
not per-vendor, configuration locations.
default /usr/lib/rpm/macros what rpm chooses
vendor /usr/lib/rpm/macros/CPU-VENDOR-OS/macros
what the distro vendor chooses to do (the @rpm5.org path
is /usr/librpm/macros.d/VENDOR to attempt per-dialect VENDOR
builds)
system /etc/rpm/*.macros
Note that /etc/rpm/macros.d is purely what Mandriva has chosen
and I see no reason for the added "macros.d" crapola in
/etc/rpm.
In /usr/lib/rpm there's so much crap -- and rpm5.org <-> rpm.org
incompatibilities -- that a subdir is needed and "macros.d"
avoids
having to discuss out at the pikeshed
user ~/.rpmmacros
Which vendors have ALOS aquatted with
~/buildroot/{SOURCES,RPMS,SPECS}
which is no hierarchy I like and I resent having it inflicted on
my personal configuration which is now broken differently in
each and every release from rpm.org from every single vendor.
If you start using splats, there's no way to tell what SHOULD/COULD/WOULD
happen when rpmbuild is invoked, because configuration gets dynamically
convolved with de facto what is present in /etc/rpm/macros.d/*.macros.
Note that %{load:...} permits URL's. If you want to head towards a URI
containing
the contents of vendor (or interpreter) specific configuration, then globs
(which SHOULD work but noone lets me work on rpmio which I actually would enjoy
fixing), then my objection
When a build breaks you haven't ANY clue why the build broke ...
starts to not apply becuase a URL can be examined for what SHOULD be there
in ways that a build system can NOT be examined, and splats START to make some
sense there. But since network transport is STILL controversial -- even at
the level of RPM reading its OWN configuration -- this is likely non-viable as
well.
The global issue is "reproducible builds" that splats and vendir abuse
of existing hierarchical functionality and inheiritance has damaged
to the ppoint that its easier to drop rpmbuild than try to explain
what SHOULD have been done and never has been (by vendor distros)
repeatedly.
You've (all of you, vendors, build mommas, package monkeys, developers,
everyone)
had a decade to do something sensible rather than using RPM
for vendor lock-in mind-share capture. While I am an employee or contractor,
you are entitled (because you pay me for professionalism) to do whatever you
want.
OTOH, if its *MY* code and *MY* support and *MY* time that is being wasted by
vendor
derangements, I plain and simply no longer care to support ideas and
implementations
that I do not believe in.
73 de Jeff
smime.p7s
Description: S/MIME cryptographic signature
