Re: [Ganglia-developers] Three .spec file issues
On Fri, Sep 18, 2009 at 06:40, daniel.poc...@barclayscapital.com wrote: 2) The 'Release' macro is not properly set in the specfile. This is because it is defined by the @REL@ autoconf variable, which is hard-coded to 1 in configure.in. I propose that we change this. The simplest thing would be to remove @REL@ from ganglia.spec.in, and update the Release macro manually. The other option is to remember to update REL in configure.in each time a change is made to the ganglia.spec.in file. I actually introduced that variable, thinking that it would be useful to have it in a single place (configure.in) and use it for generating both the spec file and the Solaris pkginfo file. Obviously, some changes won't impact both platforms (e.g. a change within the spec file doesn't impact Solaris), but maybe someone will rebuild the packages for all platforms with no code changes but a different configure option and they will use @REL@ to show that something has changed - does that seem reasonable? Therefore, I'm not keen to go back to the manual solution, but some alternative to @r...@... Fair enough. I didn't realize it was a recent addition, and given the long %changelog, was surprised to see it still at 1. I'll add a note in the specfile about updating it, and bump the version in trunk. -- Jesse Becker -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] Three .spec file issues
On Fri, Sep 18, 2009 at 08:58, daniel.poc...@barclayscapital.com wrote: Fair enough. I didn't realize it was a recent addition, and given the long %changelog, was surprised to see it still at 1. I'll add a note in the specfile about updating it, and bump the version in trunk. I've noticed different ways of doing this, too Sometimes I see: 1.0-1 1.0-2 1.1-1 (release number reverts back to 1 on new version of code) 1.1-2 and other projects do something like: 1.0-1 1.0-2 1.1-2 (nothing changed in spec file, release number unchanged) 1.1-3 Is there any preference for how this should work in Ganglia? Can it be done in a unified way across packaging systems, or should we avoid any such unification? I prefer a monotonically non-decreasing release number (the 2nd option). -- Jesse Becker -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] Three .spec file issues
Hi all: On Fri, Sep 18, 2009 at 6:29 AM, Jesse Becker haw...@gmail.com wrote: I prefer a monotonically non-decreasing release number (the 2nd option). I personally prefer that the RPM release get resetted to 1 when we up the version number and only increase it when there are changes to the spec file and/or other changes that does not change the release tarball. It may be confusing to users why the latest Ganglia release (eg. 3.1.3) is represented as 3.1.3-22 and they would be wondering where the other 21 releases are. The spec file is tracked in SVN, so if you need to figure out what has changed, you can look at the repository changelog. Just my $0.02. Cheers, Bernard -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] Three .spec file issues
Jesse Becker wrote: On Fri, Sep 18, 2009 at 08:58, daniel.poc...@barclayscapital.com wrote: Fair enough. I didn't realize it was a recent addition, and given the long %changelog, was surprised to see it still at 1. I'll add a note in the specfile about updating it, and bump the version in trunk. I've noticed different ways of doing this, too Sometimes I see: 1.0-1 1.0-2 1.1-1 (release number reverts back to 1 on new version of code) 1.1-2 and other projects do something like: 1.0-1 1.0-2 1.1-2 (nothing changed in spec file, release number unchanged) 1.1-3 Is there any preference for how this should work in Ganglia? Can it be done in a unified way across packaging systems, or should we avoid any such unification? I prefer a monotonically non-decreasing release number (the 2nd option). I think it has always been 1 because the former approach was used, or maybe because it just isn't documented in the release procedure I actually don't think the release number is that important overall, for a few reasons: - in both of the schemes suggested above, RPM would sort the versions in the same order anyway - I can't see that there have been any releases of Ganglia where the release number has been included in the name of the tag - I can't see that there are any releases where the spec file was the only change However, if/when necessary, we could start creating multiple tags of the same version, including the release number in the tag name, where only the spec file changes, or where the only change is an improvement for the init script or config file. As noted before, @REL@ is used in solaris/pkginfo (see trunk), and it is also intended for WiX/ganglia-gmond.wxs (also in trunk), so whatever the final decision, it may be desirable to support all of those. We could also have separate variables, @REL_RPM@, @REL_PKG@, @REL_WXS@, etc For 3.1.3, I'm leaving it as it is now, the release number is in configure.in -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] Three .spec file issues
Hi Jesse:
On Thu, Sep 17, 2009 at 7:48 PM, Jesse Becker haw...@gmail.com wrote:
1) I've made a few small changes to the ganglia.spc.in file (r2087
and r2088) to use the %{version} tag instead of @VERSION@ in a few
places. This is considered to be 'correct' according to RPM package
building, and allows for easier upgrades if a user need to take the
.spec file and update it themselves. The initial './bootstrap' will
still have to be run, since @VERSION@ does need to be expanded at
least once to define an RPM macro, and set a few items in the
comments.
Sure, so instead of changing the version in 3 places, you only need to
change it in one place.
3) There are several sub-packages created by the specfile:
libganglia-3_1_0
ganglia-python
ganglia-web (noarch)
ganglia-devel
ganglia-gmond
ganglia-gmetad
The ganglia-devel package includes a /usr/lib/libganglia.so *symlink*
that points to the actual .so included in the libganglia package. I
think that this symlink should be in the libganglia package. Is there
a particular reason it is in ganglia-devel instead?
I think this is the convention for how -devel packages are packaged --
it just includes the symlink only for the .so file.
Take a look at how files are distributed between bzip2-libs and bzip2-devel.
Cheers,
Bernard
--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
___
Ganglia-developers mailing list
Ganglia-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
