[PATCH] scripts: Make the crosstool-NG version an optional part of pkgversion
Tue Oct 18 22:46:00 GMT 2011
On Wed, Oct 19, 2011 at 10:02 AM, Yann E. MORIN
> Michael, All,
> On Tuesday 18 October 2011 21:43:19 Michael Hope wrote:
>> On Wed, Oct 19, 2011 at 5:20 AM, Yann E. MORIN
>> <firstname.lastname@example.org> wrote:
>> > Michael, All,
>> > On Monday 17 October 2011 05:39:47 Michael Hope wrote:
>> >> # HG changeset patch
>> >> # User Michael Hope <email@example.com>
>> >> # Date 1317709748 -46800
>> >> # Node ID 931a96c7b84610c33a5535f574adf01df63d1a89
>> >> # Parent 5b157f46a3ab4830e4117811e9338e7d74d3a55d
>> >> scripts: Make the crosstool-NG version an optional part of pkgversion.
>> > If I may ask, what is the reason you (Linaro) would not want to identify
>> > crosstool-NG in the pkgversion string?
>> Just brevity. We set the Linaro release as the default package
>> version, so for source builds you get a string like:
>> gcc (Linaro GCC 4.6-2011.09) 4.6.2 20110908 (prerelease)
>> For binary builds I was planning on using a pkgversion like 'Linaro
>> GCC 4.6-2011.09+bin1' to show the particular build script release used
>> to make the binary. We need to identify the build scripts to fully
>> meet the terms of the GPL.
>> > Would it be better if the crosstool-NG ID string was placed _after_ the
>> > custom string?
>> Yeah, that would be fine.
>> >> We use the pkgversion for the Linaro release name. This patch lets you
>> >> turn off the automatic crosstool-NG@revno and just use the configured
>> >> package version.
>> > Note that, for release, the 'revno' is replaced by the version string,
>> > so it is much shorter; that is, something like:
>> > crosstool-NG 1.12.4
>> >> +config TOOLCHAIN_PKGVERSION_WITH_CROSSTOOL
>> >> + bool
>> >> + prompt "Include the crosstool-NG version in the ID string"
>> >> + default y
>> >> + help
>> >> + Include the crosstool-NG version in the package version string.
>> > If this was to make it in, I would add:
>> > depends on TOOLCHAIN_PKGVERSION != ""
>> > So there's at least one pkgversion string:
>> > - the crosstool-NG ID string
>> > - the crosstool-NG + the custom ID strings
>> > - the custom ID string
>> > OK for you?
>> I'd like to withdraw the patch for now and think about it some more.
>> Linaro work upstream, but no matter what we'll end up with a branch
>> for patches that aren't upstreamable. Therefore a name like 'Linaro
>> GCC yyyy.mm + crosstool-NG r12345' isn't true as it's not crosstool-NG
>> r12345, but r12345 of our branch.
> OK, after a little talk on IRC, it seems there may have been some
> confusion in what I said above.
> IANAL and all, what follows is not legal advice, but I'll try to make it
> There is *no* requirement that "crosstool-NG" appears in the pkgversion.
> I never said that. That would be a restriction, and thus a violation of
> the GPL, and crosstool-NG is GPLv2. So, it is *absolutely not* mandatory
> to include "crosstool-NG" in the pkgversion.
> I just said that I would prefer that the _stock_ crosstool-NG, as released
> on the crosstool-ng.org website, always incorporate "crosstool-NG" in the
> pkgversion string.
> But, anyone who downloads crosstool-NG, is free to tweak it so that the
> pkgversion doe not include "crosstool-NG", _provided_ the licenses, of
> crosstool-NG itself, and the other tools used in the toolchain, are
> complied with.
> Again, the above is not legal advice. Talk to your lawyers! ;-)
> I just wanted to make that clear. Sorry for the noise...
Agreed. The GPLv2 includes the phrase "plus the scripts used to
control compilation and installation of the executable". This can be
read as "if you distribute a binary build of GCC then you also have to
make the build scripts available".
Having 'crosstool' in the pkgversion is a nice reminder of the obligation.
For unsubscribe information see http://sourceware.org/lists.html#faq
More information about the crossgcc