[Top][All Lists]
[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
signature.asc
Description: This is a digitally signed message part.
- Re: Bugs in unexpand(1) version 6.10, Mike Frysinger, 2009/02/02
- Re: Bugs in unexpand(1) version 6.10, Jim Meyering, 2009/02/03
- Re: Bugs in unexpand(1) version 6.10, Mike Frysinger, 2009/02/05
- Re: Bugs in unexpand(1) version 6.10, Jim Meyering, 2009/02/06
- Re: Bugs in unexpand(1) version 6.10, Mike Frysinger, 2009/02/09
- Re: Bugs in unexpand(1) version 6.10, Jim Meyering, 2009/02/10
- Re: Bugs in unexpand(1) version 6.10,
Mike Frysinger <=
- Re: Bugs in unexpand(1) version 6.10, Jim Meyering, 2009/02/11
- Re: Bugs in unexpand(1) version 6.10, Mike Frysinger, 2009/02/11
- Re: Bugs in unexpand(1) version 6.10, Karl Berry, 2009/02/11
- Re: Bugs in unexpand(1) version 6.10, Mike Frysinger, 2009/02/11