From: Keith M. <kei...@us...> - 2008-04-21 20:46:02
|
On Sunday 20 April 2008 22:56, Charles Wilson wrote: > > Any chance that flex could be upated from 2.5.33 to 2.5.35? There > > was apparently a fix for generated compiler warning on windows. > > Sure -- for msys-1.0.11 supplemental tools. I'm just waiting for a > resolution to these threads: > > http://thread.gmane.org/gmane.comp.gnu.mingw.user/25889/focus=2739 > which has been on hold for three weeks > > and this one > http://thread.gmane.org/gmane.comp.gnu.mingw.devel/2790 > which, as Keith mentioned > http://thread.gmane.org/gmane.comp.gnu.mingw.devel/2790/focus=2879 > is actually a continuation of the above, in his absence, > contradicting his request to place this discussion on hold while he > was away. I apologise if I seem to have been dragging my heels here. I've been back from holiday for less than a week, and have had to deal with other more pressing issues -- wife admitted to hospital sooner than expected, for surgery anticipated in July/August, due to quicker than normal NHS waiting list progression, to say nothing of the need to catch up on day job issues. > I'm not wasting my time -- AGAIN -- making or uploaded any packages > that don't meet some standard that hasn't yet been defined or > promulgated, or because the project lead(s) haven't managed to reach > a consensus. > > Contributor time is a limited resource, and forcing contributors like > me to use it up because decisions like this get made, then unmade, I certainly won't demand that you reload any package, solely to make it retrospectively conform to any yet to be agreed naming convention. > then countermanded (Earnie seems to like bzip2. Keith wants gz. I want whatever works best for the end users. bzip2 precludes WinZip as an extraction tool; (maybe that isn't such a bad thing). The bigger issue is that Windows archiving tools don't comprehend linked files in archives. That can have a huge impact on tarball sizes, which may hurt the users on download, and is especially painful for those who maintain packages, and for whom upload may be an order of magnitude slower than download. If we choose to allow linked files in archives, then that forces users to employ our nominated tools to unpack. The likes of WinZip or 7-Zip simply would not be acceptable, yet users seem to want to use them, even if doing so breaks their installation; they then complain that the packages are broken. Choosing the most appropriate packaging format is my primary concern. If we decide that that requires the use of appropriately sanctioned tools, then there is an onus on us to provide those tools. Do we really want to say that all MinGW users *must* use MSYS? It may be acceptable to have such a limitation for MSYS specific packages, but in the more general case, I don't think the users will thank us for such a policy; thus I suggest .tar.gz, with no linked files, for non-MSYS packages. If we don't adopt such a policy, then IMO, we *must* provide some form of integrated package management tool, which *must* be able to run natively with zero external dependencies, which gives users the ability to selectively download, install and manage a potentially multiversioned MinGW system. Only when we get to that point, can we legitimately require that only our package management tools are used to fulfil this role. > Others want .7z or lzma or zip or rar<shudder>. Nobody likes anybody > else's package naming convention) I don't much care what package format, or even mix of formats, or what naming convention we ultimately choose; the important thing is to end up with something which is consistent, makes sense to the end users and maintainers alike, and incorporates whatever meta-information may be required to clearly identify the purpose of each package, and to facilitate package management, (particularly if that aspect is to be automated). I took the discussion of that to the developer's list, to give us an opportunity to formulate a proposed convention, without too many cooks spoiling the broth, which we could then bring back to the users for ratification. > -- it's wasteful, and in the end > raises the bar for contributions higher than most will want to bother > with. Recompiling, repacking, and uploading one package, like flex, > is not THAT big a deal. It's when you multiply by 20 or 30 that > things get really painful. Yes, it certainly can become so. > And some wag suggested uploading multiple compression formats for the > same package? With the FRS? I am not much in favour of this, although I don't expressly rule it out, if individual package maintainers want to go to that much trouble, at least as an experiment in some tech preview package category. > Take a look at the supplementary tools > download page -- how gigantic do you want it to be? We're talking about the MSYS supplementary tools here, right? It's already bigger than I'm really comfortable with, but I don't see any realistic alternative. > Sorry you got hit with the crossfire, Bob...but frankly, this project > is starting to annoy me: I'm sorry to hear that, Chuck; I really do appreciate all your hard work. If you'd care to discuss any grievances privately, please do so, and I'll do my best to address them. > at some point an actual decision on some of > these issues needs to be made. I was hoping that once Keith returned, > something along those lines would happen quickly...but it hasn't yet. Yes, I'd like this to happen quickly too. Please bear with me: I don't think we were too far from formalising a package naming convention, and I'll try to get back to it in the next day or two. Regards, Keith. |