[Nut-packaging] RPM .spec files in NUT source tree

[Arnaud Quette]

2008/12/14 Charles Lepple <clepple at gmail.com>:
> All,

Hey there,

as a side note, this point is linked to the "make package" target in NUT 2.4.0

> Arnaud and I were discussing the *.spec files we have in the NUT
> source tree, and with the 2.4.0 release of NUT just around the corner,
> I would like to make sure we are pointing people in the right
> direction for NUT RPMs.
>
> Currently, we have *.spec files for "generic-rpm" (has a few macros
> for RedHat 6.x and 7.x), Mandriva (circa NUT 2.0.2), openSUSE, and
> RedHat (apparently from RawHide).
>
> Since we do not have many developers who use the *.spec files
> (although Arjen keeps the openSUSE directory up-to-date), I am not
> sure if we are doing the packagers a disservice by shipping old
> package descriptions. We try to keep the version numbers updated via
> autoconf macros, but without testing, the list of drivers and man
> pages can get stale.
>
> Also, by having several different spec files in the release tarball,
> we are probably breaking "rpmbuild -tb" (if memory serves, this is the
> option that finds the .spec file inside a release tarball).
>
> My question to the packagers: Would you prefer that we include a
> README file with a link to your website where you keep information
> about your NUT packages? Or is it worthwhile for us to pull in your
> changes every so often, so that people who want to test new drivers
> can do so before you release a new version of NUT?
>
> Also, if there is a reference for macros that we can use to unify the
> *.spec files (using conditionals based on macros defined on your
> platform), let me know, and we'll try to incorporate that into a truly
> generic nut.spec.

I've thought a bit more about that and come to the following conclusions:
- if we are to provide the spec files, *you* distro guys have to take
care of these since it's somehow one of your development branch. At
least, this is how I handle it for Debian.
- next about the -tb situation, since the make-package target comes
with an exact system detection, we would be able to remove those
unneeded spec files, just to keep the right one. Can that fix the
issue Charles?
- now about Charles proposition of a common spec file, it's great and
in conjunction with the (still vapor) NUT Packaging Standard, would be
excellent (ex: making it easier for creating auto installer and config
wizard...)
- a README file could be nice too. but it must consider and document
the 2 cases: where the nut source is more recent than the online
distro one, along with the opposite.

***************************** IMPORTANT NOTE
*******************************************************
NUT 2.4.0-pre1 is scheduled for Dec, 25th
this means that if you have not reacted to the present mail before
that date, we will remove the packaging files for your distro, and
will keep only the generic rpm spec.
In that case, we will also do our best to do the standardisation of a
common spec file, but with a low priority.
Anyway, we would really like to work *all* together on these (hard) tasks.
 *****************************************************************************************************

> (Arnaud: I did try using rpmbuild on Ubuntu 8.04 to test the syntax of
> the spec files, and it tells me that I should be using "alien", which
> does not seem to support building RPMs except by converting from
> .debs. Looks like I would need to set up a
> chroot/dual-boot/Xen/${virtualization_system_du_jour} system to test.)

gotta check. I've not done so for ages!
now, I'll also be looking in dedicating a box at work to VM for
providing buildbot and package builds.

@Oden: btw, what's your situation? I heard about rumors, that I hope
are not true.
@Charles: can you please take care of that point for the release?
@Stanislav: there may be a room for using Novell Build Service there.
could you please elaborate on this and possibly setup somthing?
@Thierry: I'd like to see you joining the round, and help me in
integrating FreeBSD support.
in that case, you will need an Alioth account.

cheers,
Arnaud
-- 
Linux / Unix Expert R&D - MGE Office Protection Systems - http://www.mgeops.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://people.debian.org/~aquette/
Free Software Developer - http://arnaud.quette.free.fr/