On Nov 10, 2010, at 1:52 PM, Eric MSP Veith wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello,
>
> since the global macro context obviously is about to die, I'm trying to
That's not exactly true, its not like everything in RPM is suddenly
gonna change to kill off a global macro context.
What is needed is this:
ATM, RPM is carrying around >500 macros which are being
loaded everywhere and always as the "default".
In reality, there's perhaps 20-30 macros that are ever used/needed
during a build, and there's another and mostly different
set of 20-50 macros used/needed during an install.
You can see the macros used during a build in the *.src.rpm, and
there's also some option (--macrosused? I fergot) (I don't
have a VM with rpm-5.3.6 active atm or I'd give you an example).
So what is needed is to refactor the global namespace into smaller
chunks that are more easily managed. The global macro context WILL
remain with common elements, likely marked with a RDONLY marker,
because you really can't change certain parts of RPM configuration
from, say, a %define in a *.spec file, that's way too late.
> figure out how to use a per-spec/per-build macro context object to do it the
> better way. Basically, I want to populate the MC with all the stuff it
> normally has *before* parsing and then building a spec file. Is this already
> possible? Skimming through HEAD, I'm kind of confused and doubt it by now.
>
The global context is the union of the initialized macros and the CLI macros
(usually the empty set).
The initialized macros are read from the colon separated macro files list.
The rules are KISS:
the 1st file (usually /usr/lib/rpm/macros) MUST exist
other files are read in order found (globs can be used), as found.
These are the same rules as always, nothing whatsoever different.
There's a single method that loops over the colon separated paths
and loads all the macros. That is actually automagically done
when rpm is "initialized".
(aside)
What is painful with bindings is that it is NOT clear what
"initialize" means. When module is loaded? When interpreter is instantiated?
When the application chooses to "initialize"? are all sane choices, but all
have different conflicting needs.
All of RPM initialization SHOULD be dirt simple: Its kinda
Duh!, gotta initialize before using!
which is good enough for almost every application on the planet,
but somehow isn't good enough for RPM, which has to attempt
relative paths from argv[0] invocation, or set a personality in the linux
kernel, Just To Find How To Initialize.
JMHO: All very dain-bramaged, and hardly useful in the "real world",
but that is in fact the featlets/bugtures implemented in RPM for initialization.
> If this is not yet the way, how is it supposed to be done right now? Calling
> rpmInitMacros before a parseSpec currently breaks it. :-/ (*** glibc
> detected *** /usr/bin/ruby: corrupted double-linked list: 0x09f7c988 ***).
> Not populating the global macro context of course solves it, but I'd like to
> a complete macro environment. :-)
>
I'd need a more complete example because I haven't a clue what "initialize"
means
to a ruby developer.
The simplest implementation (while developing) is to bind (or add silently at
load)
rpmReadConfigFiles(NULL, NULL);
The initialized macro context ends up in a pointer, and NULL passed
to MC methods uses the global macro context.
And I'm not sure that the problem _IS_ solvable any more. RPM initialization
went awry in 1997 when uname(2) was used and "i986" was actually carried around
as
compatibility future proofing
for Intel CPU products. RPM initialization went totally whacko when IBM
decided it needed 8 different architectures and -- Ooops -- a SIGILL
handler had to be attempted in RPM in order to detect buggy hardware.
And when the kernel debutantes (but not everyone else) decided that
the pleasnat lie of "i686" everywhere and always as an arch (there
are most definitely better info sources than uname(1) or uname(2))
well RPM initialization kinda got fuzzy and crinkly and uselessly
complicated.
Disclaimer:
Handling SIGILL just to find "default" no-brainer boilerplate initialization
is quite whacko in my book. YMMV, everyone's does.
73
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
