[Distutils] Fwd: Re: distutils bdist_rpm and %postun section of spec file
a.cavallo at cavallinux.eu
Sun Sep 20 12:30:15 CEST 2009
> > Symlink is pointing to x86_64 arch file, i would like to have noarch rpm.
> > It is pointing to /usr/bin/consolehelper as application needs to be run
> > with root rights.
> > I might be doing something wrong here but this is my first package.
> Although the target (/usr/bin/consolehelper) of the symlink is a
> compiled binary and thus architecture-specific, the symlink's path and
> thus the symlink itself is architecture-independent, so it ought to be
> possible to create a noarch rpm.
Is it this relevant? In a typical system there're quite few packages: why
bother to this level of detail?
> I can think of a couple of approaches:
> (i) You can write a generic setup.py script and invoke the "bdist_rpm"
> command, as you're doing, and have this generate a specfile for your RPM
> and build it. The specfile is autogenerated.
> If I'm reading the distutils code correctly this will internally call
> the "install" command, and scrape the installed payload into a file
> named "INSTALLED_FILES", which will get referenced in the autogenerated
This solution never really worked for me: if I remember it didn't handle the
directories properly (at rpm uninstall it tries to rmdir /usr/bin =: ).
> However, reading the consolehelper manpage, it looks like you may also
> need to set up files under /etc/pam.d/ (not my area of expertise)
> (ii) You can write a generic setup.py script, and also write a .spec
> file. You then create the symlink in the specfile, and add it to the %
> files section. In Fedora we have a script "rpmdev-newspec" that makes
Cool I wish know this before: is available to the public?
> it easy to create new boilerplate .spec files for a setup.py file.
Agree, it looks the old way of bdist_rpm hasn't quite catched up with rpm
> downside to this approach is that you now have a .spec file separate
> from your setup.py, and have to maintain both. It makes sense in our
> world where Python is only one of many technologies, and rpm is the
> native packaging format (for good or ill).
It is not a big burden: I can easily manages several packages at once on my
python distro (http://pyvm.sourceforge.net).
If I can recommend I'd go for the SuSE build service: this will make easier to
experiment the "hands off" build a real rpm.
More information about the Distutils-SIG