python 2.4 upgrade

Jeff Johnson n3npq at nc.rr.com
Thu Nov 11 15:22:09 UTC 2004


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





More information about the fedora-devel-list mailing list