[Distutils] Fwd: Re: distutils bdist_rpm and %postun section of spec file

[A. Cavallo]

> > 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
> specfile.

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 
packaging recently. 

> The
> 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.

Regards,
Antonio