Re: [MinGW-dvlpr] -src packages

[Keith M. <kei...@us...>]

On Saturday 13 March 2010 08:11:13 Charles Wilson wrote:
> > So just so I don't make the mistake again, binutils, gdb and
> > make should not have 'mingw32' in the src packages, since they
> > are the pure GNU sources?
> >
> > What about mingwrt and w32api?
>
> See, this is where I differ from Keith (but, he's a maintainer,
> and I'm just a schmoe).

Your words, not mine.  While we may not always agree, I do respect 
and value your opinions, (and that applies to all of you).

> I think that the -src packages SHOULD all 
> specify the subsystem for which they (may or may not be)
> 'personalized'.

I don't have a problem with this notion, but we need to agree a 
consistent approach, and then stick with it; when we discussed this 
previously, particularly with respect to binutils, the consensus was 
that we should *not* include the mingw32 qualifier for a package 
which is, in effect, a generic source package.

> Part of that is because I have a preference for making -src
> packages like this:
>
> foo-1.0-1-mingw32-src.tar.lzma
>     some-build script
>     a patch or two
>     the "pristine" source tarball

That's all fine and dandy, when you choose to support only those 
users who are building on the same platform as you are; your build 
script is ineffective for those of us who are trying to build a 
cross-hosted tool chain.  Am I to duplicate your effort, with a 
separate yet parallel set of source packages, adapted to suit 
building for the cross-environment?  I don't think so.

Quoting your earlier message, in the same thread:
> > I've noticed the binutils-2.20.1-1-mingw32-src.tar.gz package
> > was renamed to binutils-2.20.1-1-src.tar.gz.  Is this the
> > official 'src' naming convention?
>
> Well, only when the source package is the unmodified, unpatched,
> upstream version and has not been modified for use with mingw.
>
> Since your original upload fit that category, Keith renamed it:
> http://article.gmane.org/gmane.comp.gnu.mingw.user/32323
>
> However, that's not ALL Keith did.  He also unpacked it, corrected
> the permissions on a file, and then repackaged it.

Well, to be strictly accurate, I corrected a disappointing packaging 
bug in the upstream source tarball, by re-sequencing invalid time 
stamps on two generated files, which GCS require to be generated by 
the distributor, prior to package release; (this is disappointing 
because it's an effective repetition of a bug which was previously 
fixed, following my report in respect of binutils-2.19 -- perhaps it 
was naive to expect that the upstream maintainers might take better 
care than to repeat so soon, what is effectively the same error).

> IMO, THAT 
> means it is NOT the same tarball as the original, upstream source
> package (e.g. md5sum comparison would fail)

I didn't modify the package content in any way, but technically yes, 
the change in time stamps would result in a change of MD5 sum...

> -- and I would have 
> thought that it should then have been renamed BACK to your
> original name!

...and yes, that could be seen as justification for a change in 
the name, (which in effect, we have because we've added the `-src' 
classifier).  However, it was expedient to name it as I did; I was 
responding to a bug report against the cross-compiler build script, 
which following our earlier consensus decision on on the convention 
for naming of Chris' binutils source releases, we *didn't* adapt to 
expect the mingw32 qualifier in the package name, (unlike the case 
of the mingwrt and w32api packages, for which we now *require* this 
qualifier), and thus the bug was that the available package name did 
not conform to our previously agreed convention.

So, I'm amenable to a review of that previously agreed convention, 
but I'm not prepared to keep revisiting it, time and time again.  If 
we decide to change it now, then the cross-compiler build script can 
be adapted to accommodate the change, but then *all* future releases 
*must* continue to conform to this agreement.

-- 
Regards,
Keith.