From: Charles W. <cwi...@us...> - 2010-03-13 19:32:54
|
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. how about "...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) >> '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. 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: >> >> 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. 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 violation? >> 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 ??] > 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. 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. -- Chuck |