On 3/13/2010 1:54 PM, Keith Marshall wrote:
> On Saturday 13 March 2010 08:11:13 Charles Wilson wrote:
>> See, this is where I differ from Keith (but, he's a maintainer,
>> and I'm just a schmoe).
> Your words, not mine.
"...where I differ from (what I believe is) Keith's (position)..." ?
> While we may not always agree, I do respect
> and value your opinions, (and that applies to all of you).
I did not mean to imply otherwise. I simply meant that, unless there is
disagreement between you and (earnie? cesar?), your opinions are
normative, whereas mine are only advisory. And that's fine with me; I
have no ambitions or delusions of grandeur.
>> I think that the -src packages SHOULD all
>> specify the subsystem for which they (may or may not be)
> 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.
I believe that is correct. But there were a lot of unspoken assumptions
and unexamined corner cases: such as the whole idea of two different
w32api packages derived from identical source.
I didn't feel THAT strongly about it, so I didn't object.
>> Part of that is because I have a preference for making -src
>> packages like this:
>> 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.
That's a good point.
While it would be more effort, now that I kinda have a framework of what
it takes to build-msys-world under msys, and a more-or-less
full-function msys-build-foo skeleton (*), I'd like to refactor that
into something that (a) IS a skeleton that can be customized
per-package, rather than *copied* and customized -- sort of like Cesar's
msysrlsbld, but maybe closer in spirit to Yaakov's cygport (b) is
capable of operating both when $build=msys and when $build=*nix.
And for -mingw32- packages, I've generally been using a variation of the
mingwPORT framework, simply because (a) it was there, and (b) I thought
that was the kinda semi-hemi-demi-approved procedure. But the general
structure of mingwPORTs have some problems, which make ongoing
maintenance of a ported package difficult. Also, mingwPORTs weren't
really intended for delivering pre-built software, especially with the
GPL requirement that delivering binaries requires delivering the ACTUAL
source. "Real" mingwPORTs have no source nor binaries -- just the
scripts, and they download src on the fly. But, more problematic from
our perspective, they require $build=msys. So, here too, I'd like to
see something a little more cross-platform cygport-ish. Maybe the SAME
tool as above, with different personalities set via keyword in that
per-package customization I mentioned?
(*) During the msys-build-world project last summer, I started with a
fairly simple msys-build-zlib, which got progressively more and more
capable as I added necessary features to the "skeleton" on the way to
gmp/guile/autogen (which were close to the "top of the stack"). Now, as
I rebuild msys-world using the latest msys-gcc-3.3 toolchain, I've been
updating (e.g.) msys-build-zlib with that bigger skeleton.
To answer your question, I don't think you should worry about whether
YOUR build script works in native msys. Just include *yours* which
works for you in your cross env. Sure, that makes it harder for *me* to
reproduce your effort in a native msys -- but at least I know EXACTLY
what steps need to happen; my only work is translation. Ditto vice versa.
> Quoting your earlier message, in the same thread:
>> 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).
Yes, there is something broken in their release process. What
individual manages that? Rather than simply reporting the bug, can we
pinpoint the problem in the Makefile's make-dist rule that causes the
>> 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...
Yep. Metadata counts, IMO.
>> -- 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.
I understand the frustration. You're right that we need to pick a
convention, and stick with it. My fear is that if we choose the "no
subsys" convention, then how do we manage the case where/if we really DO
need to patch the source?
> 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.
Agreed. And I didn't REALLY want to reopen this can of worms; I'm
willing to live with the "other" convention if that is what we
(re)decide. [And you're right, I suppose just adding the -src tag is
sufficient to distinguish "our" tarball from the official one -- so long
as we never release a version of (e.g.) binutils at the same version
number for both msys and mingw, where one requires modifications that
the other does not. Since the msys one will *always* require
modifications, then perhaps
binutils-X.Y.Z-M-src.tar.$cmp == mingw,
binutils-X.Y-Z-M-msys-1.0.13-src.tar.$cmp == msys
> 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.
I've made my case, such as there is of it; I'll let you guys continue
and I won't raise the issue again, regardless of what is ultimately decided.