All,
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.
(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.)
thanks,
--
- Charles Lepple
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/
Citeren Charles Lepple <clepple at gmail.com>:> 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.I would prefer *not* to ship *.spec files. Usually, it is much easier to grab the latest SRPM from the distribution in question, change a couple of value and get things running again. This is how I usually deal with this, I never use the openSUSE spec file that is in the NUT development/stable version. Best regards, Arjen -- Please keep list traffic on the list
Charles Lepple wrote:> 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.If you are interested, it is possible to create a repository in the openSUSE Build Service and create an "upstream package playground" there. You can play with the latest openSUSE/Redhat/Debian spec/deb files there.> 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?I am OK with removing the spec file (and optionally even distro-specific init scripts). Having vendor specific spec files is not sufficient - integration and packaging conventions change over the time. Things working in openSUSE10/SLES10 work differently in openSUSE11/SLES11 (e. g. desktop neutral notification, hibernation). Distro maintainers often have to prepare and test migration scripts for upgrade from old to new version. Testing of for upgrade don't include upgrade from upstream spec file based .rpm to the openSUSE .rpm. Integration of NUT with the rest of distro is a very complex task. SuSE even has an openSUSE-specific document about NUT configuration details. And for example, I am just fixing issues of NUT used in combination with suspend-to-disc (hibernation). They are cleanly distro-specific packaging problems. I guess upstream doesn't want to fix them.> 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.It makes hard to maintain for you and it does not simplify things for packagers. Most packagers does not follow upstream spec file, but they base upgrade on distro specific spec file from previous version. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec at suse.cz Lihovarsk? 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/
On Sun, 14 Dec 2008 13:36:22 -0500 "Charles Lepple" <clepple at gmail.com> wrote:> 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?This is my "me too" mail: I join those who don't think having the distribution specific spec files in upstream sources is any benefit to the users or packagers -- just for Fedora there are F-9, F-10, Rawhide, EPEL-4 and EPEL-5 versions and each of them might (and do) differ from the upstream ones and from each other too... One more note: I just handled the NUT maintainership to my collague Michal Hlavinka (cc:-ed) so I abuse this thread to announce the change and kindly ask you to direct any Fedora packaging issues at him. Best regards, -- Tom?? Smetana Sr. Software Maintenance Engineer, Red Hat RH IRC: #brno #devel #base-os #seg-team; Freenode IRC: #fedora-devel