[SSSD] [PATCH] Added sssd --version option
Jakub Hrozek
jhrozek at redhat.com
Wed Nov 30 10:24:12 UTC 2011
On Tue, Nov 29, 2011 at 05:31:26PM +0100, Jan Zelený wrote:
> > Dne 21.9.2011 13:32, Stephen Gallagher napsal(a):
> > > On Wed, 2011-09-21 at 08:40 +0200, Jan Zelený wrote:
> > >> I don't quite understand. Could you please elaborate what's wrong with
> > >> the original approach you suggested? That means one configure argument
> > >> allowing to specify the version with a default version string if no
> > >> such argument is provided.
> > >
> > > Well, for one thing what I asked for in the first place was
> > > impossible :-/
> > >
> > > We can't have multi-line version strings in a configure option; autoconf
> > > can't handle it. (All that happens is that the config.h is broken)
> >
> > Actually, it can handle it. Although not directly (you have to put \n on
> > the end of line):
> >
> > $ ./configure --with-distro-version="-3.fc15\n\
> >
> > > Built: 2011-09-07" --enable-silent-rules
> >
> > $ ./sssd --version
> > 1.7.0-3.fc15
> > Built: 2011-09-07
>
> I can confirm this works as described by Pavel.
>
> > > So I was trying to think of an alternative that would serve our needs
> > > better. Though admittedly, at this point I'm starting to wonder at the
> > > usefulness of this feature at all.
> > >
> > > So my new thought was that we should default to displaying a version
> > > that includes build-time information. Then if we wanted to display just
> > > an official version (or a distro-specific build) we could do so by using
> > > a --release argument.
I still prefer --version over --release. It's the standard switch
everyone uses.
> > >
> > > This way at least, we would be able to identify work-in-progress builds
> > > easily as compared to official release builds.
> >
>
> I don't know if that will do any good. The only thing it will do is make it
> possible to distinguish between work-in-progress build and official release.
> This can be achieved by current patch as well, you can add a value to
> PRERELEASE_VERSION when releasing new tarball (of course, the semantic of the
> PRERELEASE_VERSION would be a bit different at that point). Due to this, I'd
> like to consider this patch ACKed.
>
> Any other opinions?
>
I thought the real value was identifying distribution patchlevels
easily?
More information about the sssd-devel
mailing list