Would I be stepping on any toes if I posted a bdist_rpm patch? I am writing one as an exercise in learning Distutils internal functions, but I don't know if someone else is already working on an official version. -- Harry Henry Gebel, Senior Developer, Landon House SBS West Dover Hundred, Delaware "Why do you look for the living among the dead? He is not here, but has risen." Luke 24:5 (NRSV)
On 24 April 2000, Harry Henry Gebel said:
Would I be stepping on any toes if I posted a bdist_rpm patch? I am writing one as an exercise in learning Distutils internal functions, but I don't know if someone else is already working on an official version.
Hey, step on any toes you like. I'll be ever so *slightly* peeved, because this means I'll have to learn about Wise or Debian or some other packaging/installer system in order to get any credit for generating smart built distributions. But I'll get over it in oh, about 20 seconds. BTW, here's the interface I had in mind for bdist_rpm: Basic incantation to build a binary RPM: setup.py bdist --format=rpm # creates binary RPM OR setup.py bdist_rpm To build a source RPM: setup.py bdist --format=srpm OR setup.py bdist_rpm --source Any RPM-specific options should be supplied to bdist_rpm, ie. if you want to do anything out of the ordinary, you need to run bdist_rpm, rather than "bdist --format={rpm,srpm}". There should be a "--arch" ("--plat"?) option to "build_rpm" to let people specify the RPM architecture string; it should default to the result of 'util.get_platform()' (eg. "linux2-i586", "sunos5-sun4u"). Some rules/heuristics/hacks: * if not self.distribution.has_ext_modules(): use "noarch" for the architecture specification in the RPM MAYBE: * if util.get_platform() =~ /linux-i\d86/: use "i386" for the architecture specification in the RPM The latter strikes me as vaguely ugly, but it will make life easier for people generating RPMs for i86 Linux boxen. Perhaps a similar hack should be done for the other major Linux platforms, eg. Alpha, SPARC, PPC, ...? I dunno what Red Hat's convention for naming RPMs on those platforms is; I'm not entirely sure we should follow Red Hat's lead here (what do Mandrake and SuSE use for architecture strings in RPM filenames?). One idea that has bounced around in my head is to have a "--cheat" or "--nasty" option which skips the whole RPM machinery and just creates the damn binary RPM. This is purely a speed optimization, and not something that would save a lot of time overall, so feel free to ignore me (or accuse me of smoking something weird, etc.). Might require direct access to librpm.a, which is a no-no: I don't want Distutils to rely on any extensions apart from string, re, os, and sys. And finally, these are just ideas -- feel free to implement whatever seems right/natural/logical. Thanks a bunch! Greg -- Greg Ward - programmer-at-large gward@python.net http://starship.python.net/~gward/ Money is a powerful aphrodisiac. But flowers work almost as well.
Hey, step on any toes you like. I'll be ever so *slightly* peeved, because this means I'll have to learn about Wise or Debian or some other packaging/installer system in order to get any credit for generating smart built distributions. But I'll get over it in oh, about 20 seconds.
Okay, I hope to have a working system ready tonight for simple cases (of which both the Distutils themselves and PyNcurses are examples) probably no options in the initial version, more as I get more practice with Distutils internals. Also, this morning I added two options to the 'install' command specifically for use inside RPM spec files, I will include them in the rpm patch w/ more details. -- Harry Henry Gebel, Senior Developer, Landon House SBS West Dover Hundred, Delaware "Why do you look for the living among the dead? He is not here, but has risen." Luke 24:5 (NRSV)
Greg Ward writes:
Any RPM-specific options should be supplied to bdist_rpm, ie. if you want to do anything out of the ordinary, you need to run bdist_rpm, rather than "bdist --format={rpm,srpm}".
Sounds like a reasonable plan.
There should be a "--arch" ("--plat"?) option to "build_rpm" to let people specify the RPM architecture string; it should default to the result of 'util.get_platform()' (eg. "linux2-i586", "sunos5-sun4u").
Why?
Some rules/heuristics/hacks: * if not self.distribution.has_ext_modules(): use "noarch" for the architecture specification in the RPM
MAYBE: * if util.get_platform() =~ /linux-i\d86/: use "i386" for the architecture specification in the RPM
The latter strikes me as vaguely ugly, but it will make life easier for people generating RPMs for i86 Linux boxen. Perhaps a similar hack
It seems that for each util.get_platform() there will be a single value; these can simply be cataloged and a dictionary containing the mapping stored in the sources (it's not a large dictionary!). -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> Corporation for National Research Initiatives
On 25 April 2000, Fred L. Drake, Jr. said:
There should be a "--arch" ("--plat"?) option to "build_rpm" to let people specify the RPM architecture string; it should default to the result of 'util.get_platform()' (eg. "linux2-i586", "sunos5-sun4u").
Why?
Because the convention, at least in Red Hat-land, is that RPMs for Linux on the Intel x86 platform are named like "foo-1.23-1.i386.rpm" or "bar-3.21-3.noarch.rpm". IOW, the architecture string is not easily deducible from 'os.uname()' or 'distutils.util.get_platform()'. No matter how many hacks and heuristics we have to do the "right" thing, especially since there's more to RPM-based Linux distributions than Red Hat. (F'r example, SuSE would call the above to "foo.rpm" and "bar.rpm". Never mind the dubious wisdom of this convention, that's how they do it.)
It seems that for each util.get_platform() there will be a single value; these can simply be cataloged and a dictionary containing the mapping stored in the sources (it's not a large dictionary!).
I don't want 'get_platform()' to get out of hand -- at some point, I might as well just steal MAL's platform.py, which strikes me as overkill. (At least for now it does...). Anyways, any time you start adding hacks 'n heuristics, you need an escape hatch: that's what the "--arch" option to "bdist_rpm" is for. Greg -- Greg Ward - Unix nerd gward@python.net http://starship.python.net/~gward/ Just because you're paranoid doesn't mean they *aren't* out to get you.
Since bdist_rpm implies RPM-only, how about using the default architecture from the rpmrc file? Mark Alexander mwa@gate.net On Tue, 25 Apr 2000, Greg Ward wrote:
Date: Tue, 25 Apr 2000 21:00:56 -0400 From: Greg Ward <gward@ase.com> To: distutils-sig@python.org Subject: Re: [Distutils] bdist_rpm
On 25 April 2000, Fred L. Drake, Jr. said:
There should be a "--arch" ("--plat"?) option to "build_rpm" to let people specify the RPM architecture string; it should default to the result of 'util.get_platform()' (eg. "linux2-i586", "sunos5-sun4u").
Why?
Because the convention, at least in Red Hat-land, is that RPMs for Linux on the Intel x86 platform are named like "foo-1.23-1.i386.rpm" or "bar-3.21-3.noarch.rpm". IOW, the architecture string is not easily deducible from 'os.uname()' or 'distutils.util.get_platform()'. No matter how many hacks and heuristics we have to do the "right" thing, especially since there's more to RPM-based Linux distributions than Red Hat. (F'r example, SuSE would call the above to "foo.rpm" and "bar.rpm". Never mind the dubious wisdom of this convention, that's how they do it.)
It seems that for each util.get_platform() there will be a single value; these can simply be cataloged and a dictionary containing the mapping stored in the sources (it's not a large dictionary!).
I don't want 'get_platform()' to get out of hand -- at some point, I might as well just steal MAL's platform.py, which strikes me as overkill. (At least for now it does...).
Anyways, any time you start adding hacks 'n heuristics, you need an escape hatch: that's what the "--arch" option to "bdist_rpm" is for.
Greg -- Greg Ward - Unix nerd gward@python.net http://starship.python.net/~gward/ Just because you're paranoid doesn't mean they *aren't* out to get you.
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://www.python.org/mailman/listinfo/distutils-sig
Mark W. Alexander writes:
Since bdist_rpm implies RPM-only, how about using the default architecture from the rpmrc file?
Excellent! The only thing to think about is the arch/noarch distinction, which we have to be aware of anyway. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> Corporation for National Research Initiatives
On 25 April 2000, Mark W. Alexander said:
Since bdist_rpm implies RPM-only, how about using the default architecture from the rpmrc file?
'Cause I totally forgot about the rpmrc file, of course! Hmmm... I don't see anything in my /etc/rpmrc which would set the architecture string, though. Does RPM just figure it out for the current platform? Also, is there any sort of standard emerging for better platform strings in RPM filenames? "foo-1.3.4-1.i386.rpm" doesn't really cut it if you want to live in a world where Solaris, Linux, and *BSD all use RPMs. (Yes yes, I know they *don't*, but it's a nice idea...) Greg PS. as I mentioned earlier, the "noarch" distinction is easily handled: "if not self.distribution.has_ext_modules()" somewhere in the bdist_rpm command. -- Greg Ward - Linux geek gward@python.net http://starship.python.net/~gward/ We have always been at war with Oceania.
Also, is there any sort of standard emerging for better platform strings in RPM filenames? "foo-1.3.4-1.i386.rpm" doesn't really cut it if you want to live in a world where Solaris, Linux, and *BSD all use RPMs. (Yes yes, I know they *don't*, but it's a nice idea...)
I did a quick skim through rpmfind.net, and all of the Solaris RPMs I saw had solaris within the package name, but I think this was a convention one packager and not a standard of any kind. -- Harry Henry Gebel, Senior Developer, Landon House SBS West Dover Hundred, Delaware PyNcurses ncurses binding for Python: http://pyncurses.sourceforge.ne
After poking and proding in all the places rpmrc is supposed to be looked for..... rpm --showrc (duh.) The first section shows the architecture info. AND, rpm CAN be used on Solaris, BSD, HP-UX, whatever. It's just a complete pain, mostly trying to get it to know about all the dependencies that already live on the box. You're better off with a bdist routine for each package type. Mark Alexander mwa@gate.net On Wed, 26 Apr 2000, Greg Ward wrote:
Date: Wed, 26 Apr 2000 21:11:43 -0400 From: Greg Ward <gward@ase.com> To: distutils-sig@python.org Subject: Re: [Distutils] bdist_rpm
On 25 April 2000, Mark W. Alexander said:
Since bdist_rpm implies RPM-only, how about using the default architecture from the rpmrc file?
'Cause I totally forgot about the rpmrc file, of course! Hmmm... I don't see anything in my /etc/rpmrc which would set the architecture string, though. Does RPM just figure it out for the current platform?
Also, is there any sort of standard emerging for better platform strings in RPM filenames? "foo-1.3.4-1.i386.rpm" doesn't really cut it if you want to live in a world where Solaris, Linux, and *BSD all use RPMs. (Yes yes, I know they *don't*, but it's a nice idea...)
Greg
PS. as I mentioned earlier, the "noarch" distinction is easily handled: "if not self.distribution.has_ext_modules()" somewhere in the bdist_rpm command.
-- Greg Ward - Linux geek gward@python.net http://starship.python.net/~gward/ We have always been at war with Oceania.
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://www.python.org/mailman/listinfo/distutils-sig
participants (4)
-
Fred L. Drake, Jr. -
Greg Ward -
Harry Henry Gebel -
Mark W. Alexander