bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bugs in unexpand(1) version 6.10


From: Mike Frysinger
Subject: Re: Bugs in unexpand(1) version 6.10
Date: Tue, 10 Feb 2009 15:21:43 -0500
User-agent: KMail/1.11.0 (Linux/2.6.28; KDE/4.2.0; x86_64; ; )

On Tuesday 10 February 2009 15:10:59 Jim Meyering wrote:
> Mike Frysinger wrote:
> > On Friday 06 February 2009 01:13:13 Jim Meyering wrote:
> >> Pádraig Brady wrote:
> >> > Mike Frysinger wrote:
> >> >> On Tuesday 03 February 2009 03:28:58 Jim Meyering wrote:
> >> >>> Mike Frysinger <address@hidden> wrote:
> >> >>>> On Friday 23 January 2009 09:35:54 Pádraig Brady wrote:
> >> >>>>> What distribution are you using (I'm guessing Fedora 10).
> >> >>>>> Distributions that patch coreutils really should
> >> >>>>> modify the version string accordingly.
> >> >>>>
> >> >>>> if coreutils wants distros to do that, it should really facilitate
> >> >>>> things. the way gcc does it now with gcc-4.3+ is a pretty good
> >> >>>> standard: ./configure ... --with-pkgversion="some vendor/distro
> >> >>>> string" ...
> >> >>>
> >> >>> Good idea.
> >> >>> Patches welcome.
> >> >>
> >> >> do you want the gcc method or a new method ?
> >> >>
> >> >> gcc does:
> >> >>  - running `gcc --version` outputs:
> >> >>         gcc (GCC) 4.3.3
> >> >>  - running `configure --with-pkgversion=PKG` changes it to:
> >> >>         gcc (PKG) 4.3.3
> >> >>
> >> >> so the coreutils analog would be:
> >> >>  - running `ls --version` outputs:
> >> >>         ls (GNU coreutils) 6.12
> >> >>  - running `configure --with-pkgversion=PKG` changes it to:
> >> >>         ls (PKG) 6.12
> >> >>
> >> >> that way we could end up with:
> >> >>         ls (Gentoo p1.0) 6.12
> >> >> -mike
> >> >
> >> > Well I'd be a little worried about putting numbers
> >> > in there in case scripts parsing output from --version got confused
> >> > (like our bootstrap script for example).
> >> >
> >> > How about:
> >> >
> >> > ls (Gentoo coreutils) 6.12
> >> > ls (Red Hat coreutils) 6.12
> >> > ...
> >> >
> >> > Or perhaps we could use the wget example on my fedora distro:
> >> > GNU Wget 1.10.2 (Red Hat modified)
> >>
> >> Mike, if you're preparing a patch, please
> >> put the distro information inside the parentheses,
> >> and after "GNU coreutils", i.e., do something like this:
> >>
> >>    ls (GNU coreutils, Gentoo p1.0) 6.12
> >>
> >> Whether it has distro-specific patches doesn't change
> >> the fact that it's part of the "GNU coreutils" package,
> >> so it should continue to say that.
> >
> > i was thinking a common change to the version-etc module to add a
> > "packager" field rather than having every package out there allow people
> > to tweak PACKAGE_NAME.  what do you think of that ?
>
> Sounds sensible.
> The question then becomes whether to change version_etc
> (probably not), or to add a new interface that takes
> the additional parameter.
>
> Does anyone prefer to add a parameter to version_etc?

i prefer modifying version_etc as this would go a long way in acknowledging 
that end users are not the main consumer of software.  they get it by way of 
distro packagers.

however, i dont think it needs to modify the function prototype ?  if the m4 
set up a PACKAGE_PACKAGER define, the version_etc module could use that.  if 
the person running configure doesnt specify the --with-packager=... option, 
then  it wont show up in the output.
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]