Alan Milligan wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
| There is nothing at all stopping you (or Fedora) from configuring rpm in
| /usr/lib/rpm/redhat/macros,
| /etc/rpm/macros or ~/.rpmmacros if you wish. You can also add the
| definitions to your own
| package spec files.
|
Of course that's what we've already done. However the full power of
this is only felt when a significant number of Python spec files take
advantage of the same macros. The community cannot work with what is
yet to be published.
The "full power" is a pipe dream. There are at least 5 active forks of rpm in the world today, all of which are changing default macros to taste.
We actually had this reflected in ALL of our RH9 Python specs but the only avenue to contribute this work now is to agitate for change on a mailing list...
So agitate. There is nothing stopping Fedora (or the python package) from adding to rpm configuration by changing /usr/lib/rpm/redhat/macros in the redhat-rpm-config package, or (even better imho) by dropping in /etc/rpm/macros.python from the python-devel package.
Honking at rpm is driving backwards imho, as the concept that "One config for all, all for one config" in rpm has not been realistically achievable since RHL 6.2.
| What stops adding to rpm default configuration -- aside from the | instantly induced build | failures with older versions of rpm This cannot be so. No spec file is yet to reference these 'new' macros.
No use in Fedora spec files, sure.
| I've asked python guys regarding retrieving /usr/lib or /usr/lib64 paths
| portably from python,
| and have no clear indication one way or the other of the Right Thing
To Do.
Harold Hoyer's contributed these multilib functions and I assume he's
thought quite carefully about them. In the unlikely event of a macro
not working in a specific instance, the packager would surely not use it ...
Um, with no offense to Harold, I look before I leap. And I assume nothing about how packagers behave either.
| | Get me confirmation that the changes work with python 2.[01234], and | perhaps python 1.5, | currently deployed and I will be happy to add default macros to rpm.
This is a very moot point, and one that I see many people here contending with in various forms across a range of applications.
While RH itself is obliged to support many code bases, Fedora doesn't
necessarily need to do so! Anchoring Fedora with the rest of RH is
surely against the spirit of it's conception, and many of us would be
concerned about continued participation (if you could call it that) in
the project on that basis.
So fork rpm for Fedora, that's basically the starting point for most distros.
As I said, "One config for all, and all for one config" as a concept died in RHL 6.2
and really doesn't make much sense in the first place. Adding macros for a build system is
a configuration, not an implementation, issue.
Yes RH needs to support this, but not Fedora. That is what source code control, branches etc is about. Using this arguement as a basis to dictate what's in and what's out sucks!
| Otherwise, it | seems kinda pointless to add default macros that don't just "work" | everywhere imho.
Come now, even you cannot believe it can be that hard for a group of hard-core Python programmers to sit down and agree upon and publish four macros!
Hehe, wanna bet? Me, I program in C, not python.
73 de Jeff
