From: Keith M. <kei...@us...> - 2010-07-26 21:47:33
|
Following on from Chuck's posting: http://thread.gmane.org/gmane.comp.gnu.mingw.devel/3980/focus=4041 > >> I think the next set would include: > >> > >> sed > >> grep > >> gawk > >> less > >> findutils > >> diffutils > >> gzip > > > > I'd also be inclined to add at least one of the archiving tools > > fairly quickly; perhaps msys-tar rather than msys-libarchive > > (bsdtar), since that is what most users will probably expect. > > OK. > > >> expat > >> regex Having published those manifests needed to deliver "msys-tiny", (and "msys-base" as an exact duplicate), a week ago, today I've extended "msys-base" to now also include grep, sed, awk and the balance of the extended "msys-core" package, (as specified in "msys-core-ext"). I think I'll tackle "msys-tar" next -- I'd have liked to have had it available today; IIRC, that also requires gzip, bzip2 and xz. -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2010-07-27 00:11:40
Attachments:
msys-phase1-manifests-round3.patch
|
On 7/26/2010 5:47 PM, Keith Marshall wrote: > > Having published those manifests needed to deliver "msys-tiny", (and > "msys-base" as an exact duplicate), a week ago, today I've extended > "msys-base" to now also include grep, sed, awk and the balance of the > extended "msys-core" package, (as specified in "msys-core-ext"). All three of the updated manifests (sed, grep, gawk) look fine to me. I tested via: unpack mingw-get tarball cp var/lib/mingw-get/data/default.xml var/lib/mingw-get/data/profile.xml # modify profile.xml: commented out the mingw32 repo; set the install # location for the msys repo to a brand new temporary install location mingw-get update msys mingw-get install msys-base And it worked as expected. I do have some comments vis some of the "old" updated manifests (msys-core.xml, msys-gettext.xml, msys-regex.xml, msys-termcap.xml); I'm posting the patch and my reasoning here, but we're down to stylistic issues now. > I think I'll tackle "msys-tar" next -- I'd have liked to have had it > available today; IIRC, that also requires gzip, bzip2 and xz. Nice. msys/msys-core.xml ------------------ For this package, and this package only out of all of the msys-* ones, the -bin package probably should <require> the -lic and -doc packages. We need to at least have SOME documentation installed describing the whole enchilada, even if the rest of the per-package docu is strictly optional. msys/msys-gettext.xml --------------------- I think you forgot to remove the old 0.17-1 versions Also, for the <component class="dll"> (libintl and libgettextpo), the <requires> strategy was 'if X depends on a DLL provided by numbered package, then that <require>ment should go inside the <release /> tag'. msys/msys-regex.xml ------------------- Ditto for the <component class="dev"> depending on the dll. Some other release of <dev> might require a differently numbered version of the dll. msys/msys-termcap.xml --------------------- Ditto for libtermcap-dev depending on -dll. Also, no need to list termcap-bin here in the requires; that falls under the 'transitive requirements are ok, within the same manifest' exception. -- Chuck |
From: Keith M. <kei...@us...> - 2010-08-04 21:11:29
|
On Tuesday 27 July 2010 01:11:19 Charles Wilson wrote: > > I think I'll tackle "msys-tar" next -- I'd have liked to have had > > it available today; IIRC, that also requires gzip, bzip2 and xz. > > Nice. Okay. I've now had a look at this; reviewed and tested locally: msys-diffutils.xml msys-less.xml msys-tar.xml I notice that, within the last of these, you didn't specify dependencies on msys-bzip2-bin, msys-gzip-bin or msys-xz-bin, yet all are required to achieve full functionality of tar, when processing compressed archives. Hence, I have added these missing prerequisites, and also reviewed and tested: msys-bzip2.xml msys-gzip.xml msys-xz.xml I then updated msys-package-list.xml to include these six, added their respective -bin component references as prerequisites of msys-base, in msys-base.xml, generated and pushed .lzma versions of all eight to FRS, and, after several false starts while waiting for SF's mirrors to catch up, successfully[*] used mingw-get to reinstall msys-base from scratch, (having obliterated all previous trace of it from the host). [*] I did notice one issue: during mingw-get's installation phase, some archives were processed twice; I'm investigating this. BTW, to help me keep track of what is published, I've moved the corresponding package containers, in FRS, into the MSYS/BaseSystem hierarchy. I'm also considering prefixing "msys-" to each name there, to match the XML file name, as each is addressed within msys-base.xml. With that strategy, we could then move all components which belong to msys-base into that hierarchy immediately, and use the application of the "msys-" prefix to indicate availability via mingw-get; any objection to me progressing with this strategy? Of your original list, the above leave only findutils and expat to be addressed, so I guess these two should be tackled next. Then what? msys-file and msys-make certainly belong in msys-base; maybe also msys-texinfo (for install-info). Anything else I've missed? -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2010-08-04 22:20:03
|
On 8/4/2010 11:24 AM, Keith Marshall wrote: > Okay. I've now had a look at this; reviewed and tested locally: > > msys-diffutils.xml > msys-less.xml > msys-tar.xml > > I notice that, within the last of these, you didn't specify dependencies > on msys-bzip2-bin, msys-gzip-bin or msys-xz-bin, yet all are required to > achieve full functionality of tar, when processing compressed archives. Well, for tar I don't mind either way. If you think the compressor -bin packages should be listed, that's fine. There is, however, a larger issue: there are varying degrees of "required": e.g. consider foo.exe, which is a) linked to bar.dll b) dlopen's baz.dll, but will operate with reduced functionality if baz.dll is missing c) fork/exec's castor.exe and will die if that doesn't work d) fork/exec's pollux.exe but will recover if pollux is missing, and operate with reduced functionality. So, obviously "bar.dll" and "castor.exe" are required. But what of "baz.dll" and "pollux.exe"? Are they "required" or not? I think that's a judgment call for the maintainer of the foo.exe package. (And, as with all such judgment calls, they're subject to debate and reconsideration on this list). I don't think we want to set a hard and fast rule that "anything that could conceivably be considered a requirement SHALL be listed in the xml manifest as a <requires /> element." > Hence, I have added these missing prerequisites, and also reviewed and > tested: > > msys-bzip2.xml > msys-gzip.xml > msys-xz.xml As I said, for msys-tar.xml, that's fine with me. > I then updated msys-package-list.xml to include these six, added their > respective -bin component references as prerequisites of msys-base, in > msys-base.xml, generated and pushed .lzma versions of all eight to FRS, > and, after several false starts while waiting for SF's mirrors to catch > up, successfully[*] used mingw-get to reinstall msys-base from scratch, > (having obliterated all previous trace of it from the host). > > [*] I did notice one issue: during mingw-get's installation phase, some > archives were processed twice; I'm investigating this. I'll look closely at the updated two, and new six, manifests later tonight. Also, I'll test the installation as well, so you'll have independent verification. > BTW, to help me keep track of what is published, I've moved the > corresponding package containers, in FRS, into the MSYS/BaseSystem > hierarchy. I *really* don't like this. I was hoping we would move AWAY from categorizing independent modules by which meta package pulled them in, since there will be several modules that are pulled in by multiple meta packages. Who "wins"? Besides, libiconv and gettext are NOT part of the actual msys-base installation, IIRC. Their manifests have been completed "so soon" only because they provide the libiconv-dll and libintl-dll components, which -- while ALSO not explicitly part of msys-base per se -- are pulled in as requirements of packages which ARE. So...should libiconv and gettext be in "BaseSystem" -- or in "MSYS Developer" since those are the only folks that would need the msys import libs for msys-libiconv-2.dll etc? It's this whole area of confusion that made me happy to abandon the old (FRS-circa-2006-driven) categorization. Granted, there is less of an issue now since all the files can be accessed via the flat 'download' namespace, but really -- if you need to keep track of which manifests have been updated and which have not, write it down somewhere, or create a wiki page. Or just look at what's still commented out in msys-package-list.xml. > I'm also considering prefixing "msys-" to each name there, > to match the XML file name, as each is addressed within msys-base.xml. And...we just got finished REMOVING the "MSYS ..." prefix from all of those packages! You can't complain to the sf.net guys for monkeying around with the FRS directory structure one day, and then next day churn that same directory structure back and forth yourself. "msys-foo" is better than "MSYS foo" tho, I'll grant you that. > With that strategy, we could then move all components which belong to > msys-base into that hierarchy immediately, and use the application of > the "msys-" prefix to indicate availability via mingw-get; any > objection to me progressing with this strategy? Are you talking about embedding this knowledge within mingw-get's source code, or simply as a social engineering indicator for us humans, that "msys-less" is ready, but "findutils" is not? If the former, then I do object. If the latter, well -- ok, but can we please stop renaming stuff soon? > Of your original list, the above leave only findutils and expat to be > addressed, so I guess these two should be tackled next. Then what? > msys-file and msys-make certainly belong in msys-base; maybe also > msys-texinfo (for install-info). Yes, here's the "old" MSYS-1.0.11 src directory: MSYS-1.0.11/ gzip-1.2.4a-MSYS-1.0.11-1/ bash-3.1-MSYS-1.0.11-1/ less-358-MSYS-1.0.11-1/ bzip2-1.0.3-MSYS-1.0.11-1/ lzma-4.43-MSYS-1.0.11-2/ coreutils-5.97-MSYS-1.0.11-1/ m4-1.4.7-MSYS-1.0.11-1/ cpmake-3.81-MSYS-1.0.11-1/ patch-2.5.4-MSYS-1.0.11-1/ diffutils-2.8.7-MSYS-1.0.11-1/ rxvt-2.7.2-MSYS-1.0.11-1/ file-4.16-MSYS-1.0.11-1/ sed-3.02-MSYS-1.0.11-1/ findutils-4.3.0-MSYS-1.0.11-3/ tar-1.19.90-MSYS-1.0.11-2/ gawk-3.1.5-MSYS-1.0.11-1/ texinfo-4.11-MSYS-1.0.11-1/ grep-2.4.2-MSYS-1.0.11-1/ So texinfo should definitely be in there (although we have agreed that rxvt should NOT). > Anything else I've missed? Here's the msys-base list I originally posted. I don't think there was too much argument about its contents, given the old contents above. The only controversial element is msys-cygutils-dos2unix, but that's just replacing the eponymous scripts that were added then removed circa 1.0.12: <requires ge="msys-core-*-msys-*-bin.tar" /> <requires ge="msys-bash-*-msys-*-bin.tar" /> <requires ge="msys-bzip2-*-msys-*-bin.tar" /> <requires ge="msys-coreutils-*-msys-*-bin.tar" /> <requires ge="msys-cygutils-dos2unix-*-msys-*-bin.tar" /> <requires ge="msys-diffutils-*-msys-*-bin.tar" /> <requires ge="msys-file-*-msys-*-bin.tar" /> <requires ge="msys-findutils-*-msys-*-bin.tar" /> <requires ge="msys-gawk-*-msys-*-bin.tar" /> <requires ge="msys-grep-*-msys-*-bin.tar" /> <requires ge="msys-gzip-*-msys-*-bin.tar" /> <requires ge="msys-less-*-msys-*-bin.tar" /> <requires ge="msys-m4-*-msys-*-bin.tar" /> <requires ge="msys-make-*-msys-*-bin.tar" /> <requires ge="msys-patch-*-msys-*-bin.tar" /> <requires ge="msys-sed-*-msys-*-bin.tar" /> <requires ge="msys-tar-*-msys-*-bin.tar" /> <requires ge="msys-termcap-*-msys-*-bin.tar" /> <requires ge="msys-texinfo-*-msys-*-bin.tar" /> <requires ge="msys-xz-*-msys-*-bin.tar" /> So, still missing for a "complete" msys-base would be: msys-cygutils-dos2unix msys-file msys-findutils msys-m4 msys-make msys-patch msys-texinfo plus whatever dependencies are still outstanding (which are, I think, just expat and popt). In case I haven't mentioned it recently, thanks for your hard work on getting these manifests finalized. -- Chuck |
From: Keith M. <kei...@us...> - 2010-08-06 18:10:25
|
On Wednesday 04 August 2010 23:19:56 Charles Wilson wrote: > So, still missing for a "complete" msys-base would be: > > msys-cygutils-dos2unix > msys-file Still missing. > msys-findutils Added today. > msys-m4 Deferred, pending comment from Earnie, (and anyone else with an opinion to offer). > msys-make Still missing. > msys-patch May defer, (as m4). > msys-texinfo Still missing. -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2010-08-07 17:41:20
|
On 8/6/2010 2:09 PM, Keith Marshall wrote: > On Wednesday 04 August 2010 23:19:56 Charles Wilson wrote: >> msys-findutils > > Added today. Looks good. Tested and works. -- Chuck |
From: Charles W. <cwi...@us...> - 2010-08-04 23:06:06
Attachments:
phase3-diffs
|
On 8/4/2010 6:19 PM, Charles Wilson wrote: > I'll look closely at the updated two, and new six, manifests later > tonight. Also, I'll test the installation as well, so you'll have > independent verification. OK, the only quibbles I have with any of the latest manifests is the violation of the "rule" that all <requires> elements specifying a versioned DLL package, should be per-release. Other than that, they look good and my test installation also succeeded. -- Chuck |
From: Keith M. <kei...@us...> - 2010-08-05 20:35:28
|
On Wednesday 04 August 2010 23:19:56 Charles Wilson wrote: > On 8/4/2010 11:24 AM, Keith Marshall wrote: > > Okay. I've now had a look at this; reviewed and tested locally: > > > > msys-diffutils.xml > > msys-less.xml > > msys-tar.xml > > > > I notice that, within the last of these, you didn't specify > > dependencies on msys-bzip2-bin, msys-gzip-bin or msys-xz-bin, yet > > all are required to achieve full functionality of tar, when > > processing compressed archives. > > Well, for tar I don't mind either way. If you think the compressor > -bin packages should be listed, that's fine. There is, however, a > larger issue: there are varying degrees of "required": > ...snip... Sure, there are mandatory requirements, without which the application cannot run at all, and optional requirements, without which it may run, but with reduced functionality. > I think that's a judgment call for the maintainer of the foo.exe > package. (And, as with all such judgment calls, they're subject to > debate and reconsideration on this list). Absolutely, but in considering them, we should attempt to put ourselves in Joe User's shoes; is he likely to think that: $ tar tf tar-1.23-1-msys-1.0.13-bin.tar.lzma tar (child): lzma: Cannot exec: No such file or directory tar (child): Error is not recoverable: exiting now tar: Child returned status 2 tar: Error is not recoverable: exiting now is an acceptable reduction if functionality, if he doesn't put in the leg work to resolve the hidden dependency, or will he just deem it to be "broken"? In this case I suspect it will be the latter, so having mingw-get resolve the dependency up-front seems preferable. > I don't think we want to set a hard and fast rule that "anything that > could conceivably be considered a requirement SHALL be listed in the > xml manifest as a <requires /> element." No; as you say, it may be a judgement call, with each case considered on its own merits. > ...snip... > > BTW, to help me keep track of what is published, I've moved the > > corresponding package containers, in FRS, into the MSYS/BaseSystem > > hierarchy. > > I *really* don't like this. I was sort of expecting you to say that... > I was hoping we would move AWAY from > categorizing independent modules by which meta package pulled them > in, since there will be several modules that are pulled in by > multiple meta packages. Who "wins"? But that isn't my primary objective... > Besides, libiconv and gettext are NOT part of the actual msys-base > installation, IIRC. Their manifests have been completed "so soon" > only because they provide the libiconv-dll and libintl-dll > components, which -- while ALSO not explicitly part of msys-base per > se -- are pulled in as requirements of packages which ARE. > > So...should libiconv and gettext be in "BaseSystem" -- or in "MSYS > Developer" since those are the only folks that would need the msys > import libs for msys-libiconv-2.dll etc? > > It's this whole area of confusion that made me happy to abandon the > old (FRS-circa-2006-driven) categorization. Granted, there are overlaps... > Granted, there is less of an issue now since all the files can be > accessed via the flat 'download' namespace, but really -- if you need > to keep track of which manifests have been updated and which have > not, write it down somewhere, or create a wiki page. > > Or just look at what's still commented out in msys-package-list.xml. Sure, I could do either of these for my own benefit, (and a wiki page could even make that more public), but I'm also trying to address Joe User's concerns, AT POINT OF DELIVERY. He looks at the [too long] list of packages on the download page, and is scared off, (or at least he is STILL complaining that this is intimidating, even after we segregated MinGW and MSYS packages into separate lists). By segregating it further, I'm really trying to present a less intimidating list for those who just want a basic MSYS installation, but don't [yet] want to try out mingw-get. Yes, that means I have to list some packages in "BaseSystem" just because they provide DLLs needed for that, even though their principal content is more appropriate to a more advanced toolkit for specific development usage. Maybe we need to split what I've currently assigned to MSYS/BaseSystem into two separate hierarchies: MSYS BaseSystem DeveloperAddOnsWithDLLsNeededByBaseSystem but I can't think of a nice name for the latter category. > > I'm also considering prefixing "msys-" to each name there, > > to match the XML file name, as each is addressed within > > msys-base.xml. > > And...we just got finished REMOVING the "MSYS ..." prefix from all of > those packages! You can't complain to the sf.net guys for monkeying > around with the FRS directory structure one day, and then next day > churn that same directory structure back and forth yourself. All I'm suggesting is a rename of [virtual] package containers, with the objective of making it easier for Joe User to find the stuff he needs; if it doesn't fulfil that objective, then there is no point in doing it. Any temporary benefit it might offer to me is secondary. > "msys-foo" is better than "MSYS foo" tho, I'll grant you that. > > > With that strategy, we could then move all components which belong > > to msys-base into that hierarchy immediately, and use the > > application of the "msys-" prefix to indicate availability via > > mingw-get; any objection to me progressing with this strategy? > > Are you talking about embedding this knowledge within mingw-get's > source code, No, definitely not! > or simply as a social engineering indicator for us > humans, that "msys-less" is ready, but "findutils" is not? Primarily as an indicator to Joe User: if it's prefixed by "msys-", then mingw-get will already deliver it, and he may wish to consider this as his preferred method for installation; if it lacks that prefix, then he will still need to download and install it manually. Of course, for that to work, I'd need to state the philosophy clearly, on the wiki. > If the former, then I do object. If the latter, well -- ok, but can > we please stop renaming stuff soon? The sooner, the better, yes, but we do need to devise a hierarchy which best satisfies the preferences of the end users, (and I'm hearing their message that they don't like the current long lists, all too clearly), while still being maintainable for us. > > Of your original list, the above leave only findutils and expat to > > be addressed, so I guess these two should be tackled next. Then > > what? msys-file and msys-make certainly belong in msys-base; maybe > > also msys-texinfo (for install-info). > > Yes, here's the "old" MSYS-1.0.11 src directory: > > MSYS-1.0.11/ gzip-1.2.4a-MSYS-1.0.11-1/ > bash-3.1-MSYS-1.0.11-1/ less-358-MSYS-1.0.11-1/ > bzip2-1.0.3-MSYS-1.0.11-1/ lzma-4.43-MSYS-1.0.11-2/ > coreutils-5.97-MSYS-1.0.11-1/ m4-1.4.7-MSYS-1.0.11-1/ > cpmake-3.81-MSYS-1.0.11-1/ patch-2.5.4-MSYS-1.0.11-1/ > diffutils-2.8.7-MSYS-1.0.11-1/ rxvt-2.7.2-MSYS-1.0.11-1/ > file-4.16-MSYS-1.0.11-1/ sed-3.02-MSYS-1.0.11-1/ > findutils-4.3.0-MSYS-1.0.11-3/ tar-1.19.90-MSYS-1.0.11-2/ > gawk-3.1.5-MSYS-1.0.11-1/ texinfo-4.11-MSYS-1.0.11-1/ > grep-2.4.2-MSYS-1.0.11-1/ > > So texinfo should definitely be in there (although we have agreed > that rxvt should NOT). Well, I personally consider texinfo to be more of a development tool that as an intrinsic BaseSystem component; it's only that it provides install-info, (with no easy mechanism for building it as a standalone component), that really pulls it under the umbrella of satisfying the original MSYS mission statement, (so that "make install-info" will work for makefiles which provide it), and of course "info" itself, which becomes a useful user space tool, once the "info" files are installed. Of the rest, cpmake has now become the standard make, which I've already slated for inclusion, m4 was previously included in the MSYS-DTK, and I see little cause to promote it to msys-base now, while patch I would also tend to consider as a developer tool, although I don't rule it out for possible inclusion, and, as you note, we've already agreed to drop rxvt, while continuing to offer it only as a free standing extra, which we no longer wish to promote. > > Anything else I've missed? > > Here's the msys-base list I originally posted. I don't think there > was too much argument about its contents, given the old contents > above. The only controversial element is msys-cygutils-dos2unix, but > that's just replacing the eponymous scripts that were added then > removed circa 1.0.12: > > <requires ge="msys-core-*-msys-*-bin.tar" /> > <requires ge="msys-bash-*-msys-*-bin.tar" /> > <requires ge="msys-bzip2-*-msys-*-bin.tar" /> > <requires ge="msys-coreutils-*-msys-*-bin.tar" /> > <requires ge="msys-cygutils-dos2unix-*-msys-*-bin.tar" /> > <requires ge="msys-diffutils-*-msys-*-bin.tar" /> > <requires ge="msys-file-*-msys-*-bin.tar" /> > <requires ge="msys-findutils-*-msys-*-bin.tar" /> > <requires ge="msys-gawk-*-msys-*-bin.tar" /> > <requires ge="msys-grep-*-msys-*-bin.tar" /> > <requires ge="msys-gzip-*-msys-*-bin.tar" /> > <requires ge="msys-less-*-msys-*-bin.tar" /> > <requires ge="msys-m4-*-msys-*-bin.tar" /> > <requires ge="msys-make-*-msys-*-bin.tar" /> > <requires ge="msys-patch-*-msys-*-bin.tar" /> > <requires ge="msys-sed-*-msys-*-bin.tar" /> > <requires ge="msys-tar-*-msys-*-bin.tar" /> > <requires ge="msys-termcap-*-msys-*-bin.tar" /> > <requires ge="msys-texinfo-*-msys-*-bin.tar" /> > <requires ge="msys-xz-*-msys-*-bin.tar" /> > > So, still missing for a "complete" msys-base would be: > > msys-cygutils-dos2unix > msys-file > msys-findutils > msys-m4 > msys-make > msys-patch > msys-texinfo Which adds only cygutils-dos2unix to those identified above. You know my own reservations about dos2unix (and unix2dos), where a simple pair of shell aliases or one line scripts suffices, IMO, but for the sake of the added features these cygutils .exe variants offer, I can accept your argument for including this. > plus whatever dependencies are still outstanding (which are, I think, > just expat and popt). Okay; expat to satisfy the dangling dependency in the developer-centric components of gettext, and popt because cygutils-dos2unix needs it. > In case I haven't mentioned it recently, thanks for your hard work on > getting these manifests finalized. You're welcome. -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2010-08-05 22:01:57
|
On 8/5/2010 6:58 AM, Keith Marshall wrote: > On Wednesday 04 August 2010 23:19:56 Charles Wilson wrote: >> Yes, here's the "old" MSYS-1.0.11 src directory: >> >> MSYS-1.0.11/ gzip-1.2.4a-MSYS-1.0.11-1/ >> bash-3.1-MSYS-1.0.11-1/ less-358-MSYS-1.0.11-1/ >> bzip2-1.0.3-MSYS-1.0.11-1/ lzma-4.43-MSYS-1.0.11-2/ >> coreutils-5.97-MSYS-1.0.11-1/ m4-1.4.7-MSYS-1.0.11-1/ >> cpmake-3.81-MSYS-1.0.11-1/ patch-2.5.4-MSYS-1.0.11-1/ >> diffutils-2.8.7-MSYS-1.0.11-1/ rxvt-2.7.2-MSYS-1.0.11-1/ >> file-4.16-MSYS-1.0.11-1/ sed-3.02-MSYS-1.0.11-1/ >> findutils-4.3.0-MSYS-1.0.11-3/ tar-1.19.90-MSYS-1.0.11-2/ >> gawk-3.1.5-MSYS-1.0.11-1/ texinfo-4.11-MSYS-1.0.11-1/ >> grep-2.4.2-MSYS-1.0.11-1/ >> >> So texinfo should definitely be in there (although we have agreed >> that rxvt should NOT). [snip] > m4 was previously included in the MSYS-DTK, and I > see little cause to promote it to msys-base now Huh? Was it included in MSYS-1.0.11 by accident or something? And even if so, we've sort of adopted the definition of msys-base as "replicate the installation footprint of the monolithic msys installers" -- the most recent of which WAS msys-1.0.11, which included m4. Now, I'm not saying whether it should or shouldn't be included as a matter of first principles (who uses m4, really? except indirectly via aclocal and autoconf?). But that horse has already left the barn; m4 was part of msys-1.0.11... I think the bar for removing something from msys-base which was previously in msys-1.0.11 should be pretty high. Rxvt is a no brainer; but m4? I'm not sure why it was included in the first place, so I don't know how valid the arguments for retain/reject is. > while patch I would > also tend to consider as a developer tool, although I don't rule it out > for possible inclusion, and, as you note, we've already agreed to drop > rxvt, while continuing to offer it only as a free standing extra, which > we no longer wish to promote. I think patch was included so that at least the simpler mingwPORTs could work. >>> Anything else I've missed? >> >> Here's the msys-base list I originally posted. [snip] >> So, still missing for a "complete" msys-base would be: >> >> msys-cygutils-dos2unix >> msys-file >> msys-findutils >> msys-m4 >> msys-make >> msys-patch >> msys-texinfo > > Which adds only cygutils-dos2unix to those identified above. You know > my own reservations about dos2unix (and unix2dos), where a simple pair > of shell aliases or one line scripts suffices, IMO, but for the sake of > the added features these cygutils .exe variants offer, I can accept > your argument for including this. > >> plus whatever dependencies are still outstanding (which are, I think, >> just expat and popt). > > Okay; expat to satisfy the dangling dependency in the developer-centric > components of gettext, and popt because cygutils-dos2unix needs it. well, I can see deferring m4 and patch until last, so that others can chime in. Esp. about the rationale for m4's original inclusion. -- Chuck |
From: Cesar S. <ces...@gm...> - 2010-08-05 22:39:10
|
On 5/8/2010 19:01, Charles Wilson wrote: > > well, I can see deferring m4 and patch until last, so that others can > chime in. Esp. about the rationale for m4's original inclusion. > I do not remember any reason for including both in 1.0.11, other than they were on Earnie's 1.0.10 already. Regards, Cesar |
From: Keith M. <kei...@us...> - 2010-08-06 17:41:41
|
On Thursday 05 August 2010 23:01:47 Charles Wilson wrote: > > m4 was previously included in the MSYS-DTK, and I > > see little cause to promote it to msys-base now > > Huh? Was it included in MSYS-1.0.11 by accident or something? And > even if so, we've sort of adopted the definition of msys-base as > "replicate the installation footprint of the monolithic msys > installers" -- the most recent of which WAS msys-1.0.11, which > included m4. > > Now, I'm not saying whether it should or shouldn't be included as a > matter of first principles (who uses m4, really? except indirectly > via aclocal and autoconf?). But that horse has already left the > barn; m4 was part of msys-1.0.11... You're right; I've always assumed it came from msysDTK-1.0.1.exe, but that isn't so; it has been included in the base distribution, at least as far back as MSYS-1.0.8.exe, (and that's as far back as I care to check). > I think the bar for removing something from msys-base which was > previously in msys-1.0.11 should be pretty high. Rxvt is a no > brainer; but m4? I'm not sure why it was included in the first > place, so I don't know how valid the arguments for retain/reject is. We'd need Earnie to comment on that, if he can remember. It doesn't seem to be an obvious requirement, and is an apparent violation of the "minimalist" objective, but perhaps he identified an obscure dependency which made it necessary? I know it is a prerequisite of the autotools, and also of bison, but these aren't included in a base distribution, and I can't imagine what else that is, which might require m4. Now that we have a more granular distribution mechanism (mingw-get), this seems an ideal opportunity to review what we do consider to be fundamentally essential components of a base distribution. I'd be in favour of omitting m4 for the time being, but still publishing its manifest to permit independent installation, either manually, or as a declared prerequisite of those development packages we know for sure require it; if some other dependency surfaces later, we can always add it back into msys-base when this is identified. > > while patch I would > > also tend to consider as a developer tool, although I don't rule it > > out for possible inclusion, and, as you note, we've already agreed > > to drop rxvt, while continuing to offer it only as a free standing > > extra, which we no longer wish to promote. > > I think patch was included so that at least the simpler mingwPORTs > could work. I was thinking that too; that may be sufficient reason to just include it as an msys-base requirement. Alternatively, if we want to continue to promote mingwPORTs in their present form, we could adapt them to install patch on demand, as one of their own prerequisites. -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2010-08-07 17:40:27
|
On 8/6/2010 7:38 AM, Keith Marshall wrote: > On Thursday 05 August 2010 23:01:47 Charles Wilson wrote: >> I think the bar for removing something from msys-base which was >> previously in msys-1.0.11 should be pretty high. Rxvt is a no >> brainer; but m4? I'm not sure why it was included in the first >> place, so I don't know how valid the arguments for retain/reject is. > > We'd need Earnie to comment on that, if he can remember. It doesn't > seem to be an obvious requirement, and is an apparent violation of the > "minimalist" objective, but perhaps he identified an obscure dependency > which made it necessary? I know it is a prerequisite of the autotools, > and also of bison, but these aren't included in a base distribution, > and I can't imagine what else that is, which might require m4. > > Now that we have a more granular distribution mechanism (mingw-get), > this seems an ideal opportunity to review what we do consider to be > fundamentally essential components of a base distribution. I'd be in > favour of omitting m4 for the time being, but still publishing its > manifest to permit independent installation, either manually, or as a > declared prerequisite of those development packages we know for sure > require it; if some other dependency surfaces later, we can always add > it back into msys-base when this is identified. I agree. >> I think patch was included so that at least the simpler mingwPORTs >> could work. > > I was thinking that too; that may be sufficient reason to just include > it as an msys-base requirement. Alternatively, if we want to continue > to promote mingwPORTs in their present form, Well, the mingwPORT implementation leaves a lot to be desired IMO. If we want to continue to promote build-it-your-own-self gentoo-style ports, I'd prefer something more gentoo-ebuild-ish (e.g. you install the ebuild package itself, which contains most of the "driver" scripts. The "mingwPORT" is then just the .ebuild-style overrides and configury -- as opposed to now, where every mingwPORT is more-or-less self-contained, and includes its own copy of all of the basic scripts (and, of course, they are all SLIGHTLY different in exciting ways, since everything is customizable...) > we could adapt them to > install patch on demand, as one of their own prerequisites. Sure. I don't think we're ready to start writing manifests for mingwPORTs yet though. Let's get the manifests for all of the existing "binary" packages finalized, first! <g> So what we're contemplating is the following change in the msys-base "profile" from circa MSYS-1.0.11's monolithic installer: remove rxvt remove m4 remove patch remove lzma add xz add termcap [*] add cygutils-dos2unix [**] [*] not really an addition, since /etc/termcap used to be provided as part of msys core. [**] replacing the scripts of the same name which briefly appeared in msys core around 1.0.12. I can live with that...so let's go with it, unless somebody squawks in the next few days. -- Chuck |
From: Keith M. <kei...@us...> - 2010-08-05 20:35:36
|
On Thursday 05 August 2010 00:05:59 Charles Wilson wrote: > On 8/4/2010 6:19 PM, Charles Wilson wrote: > > I'll look closely at the updated two, and new six, manifests later > > tonight. Also, I'll test the installation as well, so you'll have > > independent verification. > > OK, the only quibbles I have with any of the latest manifests is the > violation of the "rule" that all <requires> elements specifying a > versioned DLL package, should be per-release. Well, let's call it a "strong recommendation", rather than a "rule", but you're right: if we make a recommendation, we should abide by it; these were an oversight on my part, which I should (and will) rectify. > Other than that, they > look good and my test installation also succeeded. Thanks for checking and confirming this. -- Regards, Keith. |
From: Keith M. <kei...@us...> - 2010-08-05 20:44:44
|
On Thursday 05 August 2010 12:13:42 Keith Marshall wrote: > > OK, the only quibbles I have with any of the latest manifests is > > the violation of the "rule" that all <requires> elements specifying > > a versioned DLL package, should be per-release. > > Well, let's call it a "strong recommendation", rather than a "rule", > but you're right: if we make a recommendation, we should abide by it; > these were an oversight on my part, which I should (and will) > rectify. And now, it is done. -- Regards, Keith. |
From: Keith M. <kei...@us...> - 2010-08-09 20:54:11
|
On Friday 06 August 2010 19:09:58 Keith Marshall wrote: > On Wednesday 04 August 2010 23:19:56 Charles Wilson wrote: > > So, still missing for a "complete" msys-base would be: > > > > msys-cygutils-dos2unix > > msys-file > > msys-make > > msys-texinfo > > Still missing. Added today, together with msys-popt and msys-zlib to satisfy added dependencies. I've corrected a defective dependency declaration in msys-popt, (easy to fix, but tricky to identify -- my local tree has improved diagnostics for this class of error, but this particular fault confounded even this version). -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2010-08-09 23:47:29
Attachments:
msys-developer-toolkit.xml
|
On 8/9/2010 4:54 PM, Keith Marshall wrote: > On Friday 06 August 2010 19:09:58 Keith Marshall wrote: >> On Wednesday 04 August 2010 23:19:56 Charles Wilson wrote: >>> So, still missing for a "complete" msys-base would be: >>> >>> msys-cygutils-dos2unix >>> msys-file >>> msys-make >>> msys-texinfo >> >> Still missing. > > Added today, together with msys-popt and msys-zlib to satisfy added > dependencies. I've corrected a defective dependency declaration in > msys-popt, (easy to fix, but tricky to identify -- my local tree has > improved diagnostics for this class of error, but this particular > fault confounded even this version). Oops. % vs *; sorry... I have nothing to criticize in any of the updated manifests. Installation test went fine -- but I did notice one thing: I've been running mingw-get from a cygwin bash shell, and cygwin doesn't propagate ALL environment variables from WINDOWS into the spawned children. One of those that is not propagated is %APPDATA%. So, in my /c/msys-src/__xml/_test/bin directory, which is where I've been running mingw-get from, I now have an "%APPDATA%" subdirectory. That can't be right. Besides, from C/C++ I don't think you're supposed to do a getenv("%APPDATA%"); aren't you supposed to do it this way: http://weseetips.com/2008/05/01/how-to-get-the-path-of-special-folders-in-windows/ SHGetSpecialFolderPath( 0, // Hwnd strPath, // String buffer. CSIDL_APPDATA, // CSLID of folder FALSE ); // Create if doesn't exists? That aside, we now have most of the old msys installer footprint (and what was listed in my initial msys-base.xml), except for: [1] <requires eq="msys-m4-*-msys-*-bin.tar" /> [2] <requires eq="msys-patch-*-msys-*-bin.tar" /> [3] <requires eq="msys-termcap-*-msys-*-bin.tar" /> [1] and [2] are open issues, waiting for more info. [3] is actually IN this footprint, just not explicitly: it is pulled in as a requirement of msys-libtermcap-dll-0, which itself is pulled in as a requirement of msys-bash and msys-coreutils, among others. In any event, I reckon the next manifests to validate would be msys-patch and msys-m4, whether they go into msys-base or not. Followed by some of the following (elements of msys-developer-toolkit, or whatever we choose to name "the tools that help you maintain packages for MinGW, within the msys environment." I think somebody proposed calling it the "MinGW-DTK" at one point, but historically it was called the "msysDTK". This meta package includes (at first guess): <requires eq="msys-autogen-*-msys-*-bin.tar" /> <requires eq="msys-cvs-*-msys-*-bin.tar" /> <requires eq="msys-guile-*-msys-*-bin.tar" /> <requires eq="msys-inetutils-*-msys-*-bin.tar" /> <requires eq="msys-openssh-*-msys-*-bin.tar" /> <requires eq="msys-openssl-*-msys-*-bin.tar" /> <requires eq="msys-perl-*-msys-*-bin.tar" /> <requires eq="msys-bison-*-msys-*-bin.tar" /> <requires eq="msys-flex-*-msys-*-bin.tar" /> <requires eq="msys-lndir-*-msys-*-bin.tar" /> <requires eq="msys-vim-*-msys-*-bin.tar" /> <requires eq="msys-mktemp-*-msys-*-bin.tar" /> <requires eq="msys-coreutils-*-msys-*-ext.tar" /> <requires eq="msys-bsdtar-*-msys-*-bin.tar" /> <requires eq="msys-bsdcpio-*-msys-*-bin.tar" /> but with m4 and patch added, if they are kicked out of msys-base. and: <requires eq="mingw32-autoconf-*-mingw32-*-bin.tar" /> <requires eq="mingw32-autoconf2.1-*-mingw32-*-bin.tar" /> <requires eq="mingw32-autoconf2.5-*-mingw32-*-bin.tar" /> <requires eq="mingw32-automake-*-mingw32-*-bin.tar" /> <requires eq="mingw32-automake1.4-*-mingw32-*-bin.tar" /> <requires eq="mingw32-automake1.5-*-mingw32-*-bin.tar" /> <requires eq="mingw32-automake1.6-*-mingw32-*-bin.tar" /> <requires eq="mingw32-automake1.7-*-mingw32-*-bin.tar" /> <requires eq="mingw32-automake1.8-*-mingw32-*-bin.tar" /> <requires eq="mingw32-automake1.9-*-mingw32-*-bin.tar" /> <requires eq="mingw32-automake1.10-*-mingw32-*-bin.tar" /> <requires eq="mingw32-automake1.11-*-mingw32-*-bin.tar" /> <requires eq="mingw32-libtool-*-mingw32-*-bin.tar" /> <requires eq="mingw32-libltdl-*-mingw32-*-dev.tar" /> <requires eq="mingw32-gettext-*-mingw32-*-bin.tar" /> <requires eq="mingw32-gettext-*-mingw32-*-dev.tar" /> <requires eq="mingw32-libiconv-*-mingw32-*-bin.tar" /> <requires eq="mingw32-libiconv-*-mingw32-*-dev.tar" /> Remember, this meta package requires a bunch of msys tools, but also the autotools themselves compiled in "mingw32-ish" mode and installed into /mingw/. -- Chuck |
From: Keith M. <kei...@us...> - 2010-08-10 17:36:42
|
On Tuesday 10 August 2010 00:47:17 Charles Wilson wrote: > > ... I've corrected a defective dependency declaration in > > msys-popt, (easy to fix, but tricky to identify -- my local tree > > has improved diagnostics for this class of error, but this > > particular fault confounded even this version). > > Oops. % vs *; sorry... NP. We need mingw-get to issue more effective diagnostics, when such errors creep in. Even faulty manifests have value, as test cases for tracking down weaknesses in error handling. -- Regards, Keith. |
From: Keith M. <kei...@us...> - 2010-08-10 17:36:47
|
On Tuesday 10 August 2010 00:47:17 Charles Wilson wrote: > That aside, we now have most of the old msys installer footprint (and > what was listed in my initial msys-base.xml), except for: > > [1] <requires eq="msys-m4-*-msys-*-bin.tar" /> > [2] <requires eq="msys-patch-*-msys-*-bin.tar" /> > [3] <requires eq="msys-termcap-*-msys-*-bin.tar" /> > > [1] and [2] are open issues, waiting for more info. [3] is actually > IN this footprint, just not explicitly: it is pulled in as a > requirement of msys-libtermcap-dll-0, which itself is pulled in as a > requirement of msys-bash and msys-coreutils, among others. Let's leave [1] and [2] as open issues, for the time being; in any case, I've published both msys-m4 and msys-patch today, together with msys-expat to plug the gap in the msys-gettext dependencies, and msys-vim[*], all as free-standing packages, installable by: mingw-get install msys-expat-bin mingw-get install msys-m4-bin mingw-get install msys-patch-bin mingw-get install msys-vim-bin respectively. In the case of [3], I think the present status quo is sufficient. [*] I wonder if Earnie chose to include vim in the original base distribution because msys-less expects to invoke vi, if the user hits the 'v' key. In any case, just installing msys-vim-bin alone is *not* sufficient to resolve this dependency, because it doesn't actually provide /bin/vi.exe; the user needs to copy/link /bin/vim.exe to /bin/vi.exe, or provide his own redirector script. My own preference is *not* to include msys-vim in the base package set, but rather to leave the user to choose between exporting EDITOR, so as to invoke his own preferred editor, or to manually install msys-vim, and then establish an appropriate vi --> /bin/vim.exe reference. > In any event, I reckon the next manifests to validate would be > msys-patch and msys-m4, whether they go into msys-base or not. Done, as noted above. > Followed by some of the following (elements of > msys-developer-toolkit, or whatever we choose to name "the tools that > help you maintain packages for MinGW, within the msys environment." > I think somebody proposed calling it the "MinGW-DTK" at one point, It was I who suggested that; I think it better describes its intended purpose than... > but historically it was called the "msysDTK". ...this, which I dislike both stylistically, and for the potential connotation linking it to MSYS development, rather than its intended purpose in MinGW applications development; I would prefer to deprecate this, as a (virtual) package name. > This meta package includes (at first guess): > > <requires eq="msys-autogen-*-msys-*-bin.tar" /> > <requires eq="msys-cvs-*-msys-*-bin.tar" /> > <requires eq="msys-guile-*-msys-*-bin.tar" /> > <requires eq="msys-inetutils-*-msys-*-bin.tar" /> > <requires eq="msys-openssh-*-msys-*-bin.tar" /> > <requires eq="msys-openssl-*-msys-*-bin.tar" /> > <requires eq="msys-perl-*-msys-*-bin.tar" /> > <requires eq="msys-bison-*-msys-*-bin.tar" /> > <requires eq="msys-flex-*-msys-*-bin.tar" /> > <requires eq="msys-lndir-*-msys-*-bin.tar" /> > <requires eq="msys-vim-*-msys-*-bin.tar" /> > <requires eq="msys-mktemp-*-msys-*-bin.tar" /> > <requires eq="msys-coreutils-*-msys-*-ext.tar" /> > <requires eq="msys-bsdtar-*-msys-*-bin.tar" /> > <requires eq="msys-bsdcpio-*-msys-*-bin.tar" /> > > but with m4 and patch added, if they are kicked out of msys-base. I wonder if we really need to bundle this all as just a single (vast) meta-package? Perhaps breaking it down into smaller, logically related subsets could make more sense? For example... > and: > > <requires eq="mingw32-autoconf-*-mingw32-*-bin.tar" /> > <requires eq="mingw32-autoconf2.1-*-mingw32-*-bin.tar" /> > <requires eq="mingw32-autoconf2.5-*-mingw32-*-bin.tar" /> > <requires eq="mingw32-automake-*-mingw32-*-bin.tar" /> > <requires eq="mingw32-automake1.4-*-mingw32-*-bin.tar" /> > <requires eq="mingw32-automake1.5-*-mingw32-*-bin.tar" /> > <requires eq="mingw32-automake1.6-*-mingw32-*-bin.tar" /> > <requires eq="mingw32-automake1.7-*-mingw32-*-bin.tar" /> > <requires eq="mingw32-automake1.8-*-mingw32-*-bin.tar" /> > <requires eq="mingw32-automake1.9-*-mingw32-*-bin.tar" /> > <requires eq="mingw32-automake1.10-*-mingw32-*-bin.tar" /> > <requires eq="mingw32-automake1.11-*-mingw32-*-bin.tar" /> > <requires eq="mingw32-libtool-*-mingw32-*-bin.tar" /> > <requires eq="mingw32-libltdl-*-mingw32-*-dev.tar" /> > <requires eq="mingw32-gettext-*-mingw32-*-bin.tar" /> > <requires eq="mingw32-gettext-*-mingw32-*-dev.tar" /> > <requires eq="mingw32-libiconv-*-mingw32-*-bin.tar" /> > <requires eq="mingw32-libiconv-*-mingw32-*-dev.tar" /> This group would make sense as an integrated mingw32-autotools package, with appropriate dependencies on (free-standing) MSYS packages, required implicitly, but not necessarily itemised as explicit elements of this meta-package. -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2010-08-10 18:25:08
|
On 8/10/2010 10:41 AM, Keith Marshall wrote: > On Tuesday 10 August 2010 00:47:17 Charles Wilson wrote: >> That aside, we now have most of the old msys installer footprint (and >> what was listed in my initial msys-base.xml), except for: >> >> [1]<requires eq="msys-m4-*-msys-*-bin.tar" /> >> [2]<requires eq="msys-patch-*-msys-*-bin.tar" /> >> [3]<requires eq="msys-termcap-*-msys-*-bin.tar" /> >> >> [1] and [2] are open issues, waiting for more info. [3] is actually >> IN this footprint, just not explicitly: it is pulled in as a >> requirement of msys-libtermcap-dll-0, which itself is pulled in as a >> requirement of msys-bash and msys-coreutils, among others. > > Let's leave [1] and [2] as open issues, OK. > for the time being; in any > case, I've published both msys-m4 and msys-patch today, together with > msys-expat to plug the gap in the msys-gettext dependencies, and > msys-vim[*], all as free-standing packages, installable by: > > mingw-get install msys-expat-bin > mingw-get install msys-m4-bin > mingw-get install msys-patch-bin > mingw-get install msys-vim-bin > > respectively. I'll take a look this evening. > In the case of [3], I think the present status quo is sufficient. Yes. > [*] I wonder if Earnie chose to include vim in the original base > distribution because msys-less expects to invoke vi, if the user hits > the 'v' key. In any case, just installing msys-vim-bin alone is *not* > sufficient to resolve this dependency, because it doesn't actually > provide /bin/vi.exe; the user needs to copy/link /bin/vim.exe > to /bin/vi.exe, or provide his own redirector script. > > My own preference is *not* to include msys-vim in the base package set, > but rather to leave the user to choose between exporting EDITOR, so as > to invoke his own preferred editor, or to manually install msys-vim, > and then establish an appropriate vi --> /bin/vim.exe reference. I think this was handled by msysCORE's postinstall/pi.sh script -- which (a) needs some updating, and (b) we don't run anymore. >> Followed by some of the following (elements of >> msys-developer-toolkit, or whatever we choose to name "the tools that >> help you maintain packages for MinGW, within the msys environment." >> I think somebody proposed calling it the "MinGW-DTK" at one point, > > It was I who suggested that; I think it better describes its intended > purpose than... > >> but historically it was called the "msysDTK". > > ...this, which I dislike both stylistically, and for the potential > connotation linking it to MSYS development, rather than its intended > purpose in MinGW applications development; I would prefer to deprecate > this, as a (virtual) package name. Sure, that sounds fine to me -- so long as we don't then later try to rename the "MSYS System Builder" (e.g. msys-gcc & friends) as the new "msysDTK". That would be a nightmare. >> This meta package includes (at first guess): >> >> <requires eq="msys-... >> >> but with m4 and patch added, if they are kicked out of msys-base. > > I wonder if we really need to bundle this all as just a single (vast) > meta-package? Perhaps breaking it down into smaller, logically related > subsets could make more sense? For example... > >> and: >> >> <requires eq="mingw32-autoconf... > > This group would make sense as an integrated mingw32-autotools package, > with appropriate dependencies on (free-standing) MSYS packages, required > implicitly, but not necessarily itemised as explicit elements of this > meta-package. Well, sure, but I'd be disappointed to install the "MinGW-DTK" and *not* get the autotools for managing MinGW projects. If you want to subdivide, and have a mingw32-autotools meta package, but also have MinGW-DTK which include the list of msys-* extras, PLUS mingw32-autotools as a requires:, that's fine. The MinGW-DTK is a big beast -- but that's the point: give me ALL the stuff I would need to typical mingw project maintainership: source control, remote access, perl scripting, autotools, flex/bison, etc etc... -- Chuck |
From: Charles W. <cwi...@us...> - 2010-08-11 03:23:39
|
On 8/10/2010 10:41 AM, Keith Marshall wrote: > in any > case, I've published both msys-m4 and msys-patch today, together with > msys-expat to plug the gap in the msys-gettext dependencies, and > msys-vim[*], all as free-standing packages, installable by: > > mingw-get install msys-expat-bin > mingw-get install msys-m4-bin > mingw-get install msys-patch-bin > mingw-get install msys-vim-bin > > respectively. All the .xml files look good; I manually copied them into my mingw-get's data directory and was able to install the four packages (and their dependencies; e.g. msys-expat-dll) cleanly and automatically. > [*] I wonder if Earnie chose to include vim in the original base > distribution because msys-less expects to invoke vi, if the user hits > the 'v' key. In any case, just installing msys-vim-bin alone is *not* > sufficient to resolve this dependency, because it doesn't actually > provide /bin/vi.exe; the user needs to copy/link /bin/vim.exe > to /bin/vi.exe, or provide his own redirector script. > > My own preference is *not* to include msys-vim in the base package set, I agree that vim should not be in the msys-base package set. I could see the vim package also installing a vi.exe (a copy within the tarball doesn't cost much, given .lzma compression; but the on-disk footprint would grow by 1.4MB for the extra copy, since we can't rely on hardlinks). For all of MSYS's "minimal" nature, I'm not a fan of using shell scripts (like the "vi" script previously provided) to "fake" hardlinks or other functionality that is normally provided by executables on "real" unix system. This is because shell scripts can't be invoked from a plain cmd prompt or from an IDE, while .exe's can. (Yes, yes, I know: sh -c ..., but that's just a pain). > but rather to leave the user to choose between exporting EDITOR, so as > to invoke his own preferred editor, or to manually install msys-vim, > and then establish an appropriate vi --> /bin/vim.exe reference. > >> In any event, I reckon the next manifests to validate would be >> msys-patch and msys-m4, whether they go into msys-base or not. > > Done, as noted above. and validated. Good to go. >> Followed by some of the following (elements of >> msys-developer-toolkit, or whatever we choose to name "the tools that >> help you maintain packages for MinGW, within the msys environment." >> I think somebody proposed calling it the "MinGW-DTK" at one point, ...discussion of these and later points covered in prior reply. -- Chuck |