From: Keith M. <kei...@us...> - 2010-06-21 19:59:14
|
On Friday 18 June 2010 01:48:01 you wrote: > Keith, > > Could you comment on these meta-package .xml manifests? I was hoping to find some time to play with them first, but I haven't been able to do that yet. > Specifically, whether I've gotten the syntax right for "virtual" > packages (and <requires /> elements ON virtual packages). > http://comments.gmane.org/gmane.comp.gnu.mingw.devel/3852 The only difference, in terms of mingw-get processing, between a package with class="virtual" and a regular package, is that the virtual package has <download tarname="none" /> implicitly and irrevocably asserted for each and every one of its constituent component packages, if any, and each and every one of its/their contained releases; this is interpreted by the download function, as an indication that there is no archive to fetch, and by the installation function, that there is no archive to unpack. Other than this, dependency resolution and installation tracking are performed identically, for both real and virtual packages. > Also, the following worry cropped up. Most of our mingw32 > subsystem packages are named like: > > xz-4.999.9beta_20100401-1-mingw32-bin.tar.bz2 > liblzma-4.999.9beta_20100401-1-mingw32-dll-1.tar.bz2 > > that is, there is no subsystem version before the component type. > However, I've been in the habit of representing dependencies on > those packages as follows (taken from the mingw32-xz.xml manifest, > all non-germane elements removed): > > <package name="mingw32-xz" alias="xz"> > <component class="bin"> > <requires eq="mingw32-liblzma-%-mingw32-%-dll-1.tar" /> > </component> > <licence tarname="xz-%-mingw32-%-lic.tar" /> > <source tarname="xz-%-mingw32-%-src.tar" /> > </package> Yes, I'd noticed that you were doing this. I haven't, in the mingw32 manifests I've been preparing, but if I've got the coding right, then either style should work for as long as we continue to omit subsystem version tags on mingw32 packages; (I guess I should test this). > Or, from mingw32-libarchive.xml (all non-germane elements removed): > > <package name="mingw32-libarchive" alias="libarchive"> > <component class="dll"> > <requires eq="mingw32-liblzma-*-mingw32-*-dll-1.tar" /> > </component> > </package> Same in this case... > Notice, in each case, the second '%' or '*'. Should that be there, > since there's nothing for it to match? '*' should match anything at all, including an empty field, while '%' causes the corresponding field from the requirer's own tarname to be propagated into the required spec; if the requirer's field is empty, then nothing will be copied. > I guess the question is, is the match string like a 'glob' -- in > which case '*' can match "nothing" but that would leave two > adjacent hyphens...a sequence that doesn't appear in any of our > actual package names. > > Or is it just a "pkginfo resource specifier" in which case it is > simply broken down into a set of field values, as is each candidate > package name, and only the field values are compared. (e.g. the > "hyphens" in both are actually discarded before the comparison is > made). > > I suspect it is the latter, It is. > but I'm no great shakes with lexers, so > inspecting the code doesn't really tell me much. All the lexer does is decompose the supplied tarname into an array of (char *) pointers, one for each of the line items you see when you run pkginfo.exe on the specified tarname. The decomposition is performed on a strdup'd copy of the original tarname, and the returned pointers refer to their respective substrings within that; the intervening hyphens are replaced by NUL's, in passing. The dependency resolver, and the version comparator, both of which use this array of pointers, are coded in C++ from the outset. Now, addressing your original query: > I'm pretty hazy on the correct syntax for meta/virtual packages, so > I'm not ready to check these in just yet. Instead, I'm posting > them here for comments. > > There are 4. > > msys.xml > ======== > the top level include-all-the-others manifest. Also defines the > package-group-hierarchy. Doesn't actually specify any packages of > its own. I see two issues here. The first is trivial: the catalogue attribute specs in the package-list specs should omit the .xml extension because that is already incorporated in the URI template for the repository. The second: I wonder if it is prudent to aggregate all of the separate package-list specs in this manner, might it not be more maintainable to specify appropriate subsets within msys-base.xml, msys-dtk.xml and msys-dvlpr.xml? We certainly want to avoid multiple inclusions of any individual package-list, but if we specify them all together, like this, then we need to ensure that all are published as a unit. Alternatively, we could keep them together, like this, but initially cut the list back to a minimal subset, then incrementally grow it and republish, as we publish the individual components. > Oddity: includes all of the msys-*.xml manifests, but > ALSO references the mingw32-autotool ones; I'm not sure if that's > the right thing to do, but it's necessary because the > mingw32-autotools are part of the msys-developer-toolkit meta > package. I tend to wonder if msys-dtk is not a misnomer; perhaps it would seem less confusing if this were renamed as mingw-dtk, with the new tools, which replace the old msys-dvlpr, becoming the new msys-dtk? > msys-base.xml > ======== > The core installation, approximately equivalent to the old > monolithic MSYS installer. Virtual. It's almost there, subject to deciding on the disposition of the package-list specs to resolve its dependencies (see above). However, the package spec itself does need at least one "release" spec, to make it installable, (and that *may* need to be wrapped within a "component" container, to satisfy any dependency look-up). Once you've added this, you've then effectively specified a version for the meta-package itself, so you also have the option of using '%' matching in the "requires" specs, if you deem it appropriate. > msys-developer-toolkit.xml (alias msys-dtk) > ======== > Approximately equivalent to the old msys-dtk-1.0.1 monolithic > installer. Odd in that it includes some packages that are msys and > install into /, and the mingw32-autotools that install into /mingw. Again, this needs a "release" spec, to make it installable. > Also, it needs to specify a dependency on the msys-base meta > package, but I'm not sure how to do that: > <requires ge="msys-base-*-msys-*-bin.virtual" /> > doesn't seem right, because, well, there is no tarball with that > signature. If you add: <component class="bin"> <release tarname="msys-base-1.0.14-1-msys-1.0.14-bin.virtual" /> </component> to the msys-base package spec (in msys-base.xml), you provide such a signature, relating it to a virtual tarball. (I've used ".meta", rather than ".virtual", in my own trial manifests; I guess it would be good to agree a common standard here, but I've no particular preference for either one -- can we put it to a vote, please)? > msys-system-builder.xml (alias msys-dvlpr) > ======== > Functionally equivalent to the old msysDVLPR kit, but very > different since it has the new msys-gcc/binutils, plus the > msys-flavor autotools, and the msys-core -dev/-dbg packages. Once again, it needs a "release" spec. > It > does NOT include the -dev package for any of the msys libraries > (libbz2, libarchive, libopenssl, etc). Those should be installed > as-needed, individually IMO. I don't disagree; as the actual developers, your judgement, and Cesar's, should trump mine anyway. > Also needs to specify a dependency on > the msys-base meta package. Same as in the DTK case. -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2010-06-22 03:19:05
Attachments:
msys.xml
msys-base.xml
|
On 6/21/2010 8:16 AM, Keith Marshall wrote: > On Friday 18 June 2010 01:48:01 you wrote: >> Could you comment on these meta-package .xml manifests? > > The only difference, in terms of mingw-get processing, between a > package with class="virtual" and a regular package, is that the > virtual package has > > <download tarname="none" /> > > implicitly and irrevocably asserted for each and every one of its > constituent component packages, if any, and each and every one of > its/their contained releases; this is interpreted by the download > function, as an indication that there is no archive to fetch, and by > the installation function, that there is no archive to unpack. Other > than this, dependency resolution and installation tracking are > performed identically, for both real and virtual packages. That makes sense. Thanks. > Yes, I'd noticed that you were doing this. I haven't, in the mingw32 > manifests I've been preparing, but if I've got the coding right, then > either style should work for as long as we continue to omit subsystem > version tags on mingw32 packages; (I guess I should test this). > '*' should match anything at all, including an empty field, while '%' > causes the corresponding field from the requirer's own tarname to be > propagated into the required spec; if the requirer's field is empty, > then nothing will be copied. Hmmm...so all of the <requires ge="foo-*-mingw32-bin.tar"/> specs will NOT match any actual package that has a subsystem version number, while <requires ge="foo-*-mingw32-*-bin.tar"/> will match those that DO have a subsysver and those that do NOT. But in that case, assuming a mixture of "foo" packages with and without subsysver numbers, which value is "bigger": <nothing> or <a number>? >> I guess the question is, is the match string like a 'glob' >> Or is it just a "pkginfo resource specifier" > > It is. [the latter] > >> msys.xml >> ======== >> the top level include-all-the-others manifest. Also defines the >> package-group-hierarchy. Doesn't actually specify any packages of >> its own. > > I see two issues here. The first is trivial: the catalogue attribute > specs in the package-list specs should omit the .xml extension because > that is already incorporated in the URI template for the repository. Fixed. > The second: I wonder if it is prudent to aggregate all of the separate > package-list specs in this manner, might it not be more maintainable > to specify appropriate subsets within msys-base.xml, msys-dtk.xml and > msys-dvlpr.xml? We certainly want to avoid multiple inclusions of > any individual package-list, but if we specify them all together, > like this, then we need to ensure that all are published as a unit. Well, the problem is keeping track of which packages are part of some identified subset, and which are not part of any subset but are 'included by reference' due to requires specs -- such as almost all of the DLL-providing library packages: gmp, libxml2, expat, gdbm, etc. They all have to be listed somewhere. Might as well take care of all of 'em at once, in the top-level file. As far as 'trimming things down', I can try an initial cut that specifies only a few items with a self-complete dependency set. It would be even smaller than "msys-base", but it could get us started with ironing out the kinks in that subset of the per-package manifests. > Alternatively, we could keep them together, like this, but initially > cut the list back to a minimal subset, then incrementally grow it and > republish, as we publish the individual components. I like this idea. I tried to do 'er that way at first, when I "published" the first half-dozen or so manifests -- but then the closure got bigger than I wanted to mess with. I'll keep these four files "in reserve" as the target to shoot for, and cobble together just two smaller "prototype" versions of msys.xml and msys-base.xml. That way we can defer concerns about (re)naming the other two meta packages. > I tend to wonder if msys-dtk is not a misnomer; perhaps it would seem > less confusing if this were renamed as mingw-dtk, with the new tools, > which replace the old msys-dvlpr, becoming the new msys-dtk? I'd prefer not to re-purpose an old name with a new meaning; that will just guarantee future confusion, even if it is more obviously self-consistent. How about instead: mingw-dvlpr or mingw-dtk msys-dvlpr That way, we're not redefining an old name; we're just creating a new name for an old package. Or we could leave it alone, for historical consistency. >> msys-base.xml >> ======== >> The core installation, approximately equivalent to the old >> monolithic MSYS installer. Virtual. > > It's almost there, subject to deciding on the disposition of the > package-list specs to resolve its dependencies (see above). However, > the package spec itself does need at least one "release" spec, to > make it installable, (and that *may* need to be wrapped within a > "component" container, to satisfy any dependency look-up). > > Once you've added this, you've then effectively specified a version > for the meta-package itself, so you also have the option of using '%' > matching in the "requires" specs, if you deem it appropriate. Ugh. Then you'd have to update that version every time any constituent element changed. I'd rather treat msys-base, msys-dtk, and msys-dvlpr as entities representing a certain package subset, where you get the latest available version of each individual package IN that subset. e.g. msys-base has no version. Or, if we MUST specify one, then: <component class="bin"> <release tarname="msys-base-@YYYYMMDDNN@-msys-bin.meta" /> </component> so the "version" simply represents the date on which this entire set-of-manifests was built. >> msys-developer-toolkit.xml (alias msys-dtk) >> ======== >> Approximately equivalent to the old msys-dtk-1.0.1 monolithic >> installer. Odd in that it includes some packages that are msys and >> install into /, and the mingw32-autotools that install into /mingw. > > Again, this needs a "release" spec, to make it installable. <component class="bin"> <release tarname="msys-developer-toolkit-@YYYYMMDDNN@-msys-bin.meta" /> </component> <requires ge="msys-base-*-msys-*-bin.meta" /> > I've used ".meta", > rather than ".virtual", in my own trial manifests; I guess it would > be good to agree a common standard here, but I've no particular > preference for either one -- can we put it to a vote, please)? .meta is fine by me. >> msys-system-builder.xml (alias msys-dvlpr) >> ======== >> Functionally equivalent to the old msysDVLPR kit, but very >> different since it has the new msys-gcc/binutils, plus the >> msys-flavor autotools, and the msys-core -dev/-dbg packages. > > Once again, it needs a "release" spec. Done. <component class="bin"> <release tarname="msys-system-builder-@YYYYMMDDNN@-msys-bin.meta" /> </component> <requires ge="msys-base-*-msys-*-bin.meta" /> I believe the attached form the smallest possible consistent subset with a closed dependency tree. -- Chuck |
From: Keith M. <kei...@us...> - 2010-06-22 18:06:30
|
On Tuesday 22 June 2010 04:18:32 Charles Wilson wrote: > > '*' should match anything at all, including an empty field, while > > '%' causes the corresponding field from the requirer's own > > tarname to be propagated into the required spec; if the > > requirer's field is empty, then nothing will be copied. > > Hmmm...so all of the <requires ge="foo-*-mingw32-bin.tar"/> specs > will NOT match any actual package that has a subsystem version > number, while <requires ge="foo-*-mingw32-*-bin.tar"/> will match > those that DO have a subsysver and those that do NOT. Logically yes, but I'll need to play with it some more to confirm it. > But in that case, assuming a mixture of "foo" packages with and > without subsysver numbers, which value is "bigger": <nothing> or <a > number>? Numerically, nothing is compared as zero; lexically, (for suffixes on any but the major version), nothing < anything. > I'll keep these four [MSYS specific manifest] files "in reserve" > as the target to shoot for, and cobble together just two smaller > "prototype" versions of msys.xml and msys-base.xml. > > That way we can defer concerns about (re)naming the other two meta > packages. That seems like the best way forward. > > I tend to wonder if msys-dtk is not a misnomer; perhaps it would > > seem less confusing if this were renamed as mingw-dtk, with the > > new tools, which replace the old msys-dvlpr, becoming the new > > msys-dtk? > > I'd prefer not to re-purpose an old name with a new meaning; I didn't really mean to suggest that; reading it again, I seem not to have expressed it well. What I really meant was that the msys-dtk name might be construed as more representative of what is provided by msys-dvlpr, rather than its actual, more MinGW-centric purpose, so maybe would be better deprecated. > that will just guarantee future confusion, Agreed. > even if it is more obviously self-consistent. > > How about instead: > mingw-dvlpr or mingw-dtk > msys-dvlpr > That way, we're not redefining an old name; we're just creating a > new name for an old package. Makes sense to me, but I'd like to get opinions from other members of the team too. For the former, I lean toward mingw-dtk, (or maybe to honour the project branding preferences, MinGW-DTK). > Or we could leave it alone, for historical consistency. Of course, that is always an option. > Ugh. Then you'd have to update that version every time any > constituent element changed. I'd rather treat msys-base, msys-dtk, > and msys-dvlpr as entities representing a certain package subset, > where you get the latest available version of each individual > package IN that subset. > > e.g. msys-base has no version. > > Or, if we MUST specify one, then: We must, otherwise pkginfo() can't separate the package name element from the subsystem name. > <component class="bin"> > <release tarname="msys-base-@YYYYMMDDNN@-msys-bin.meta" /> > </component> That would certainly work, as far as pkginfo() parsing requires... > so the "version" simply represents the date on which this entire > set-of-manifests was built. ...but there is a (hopefully temporary) problem with this strategy; mingw-get's dependency resolver matches the tarname attribute of a release element in the distribution manifest, as a literal strcmp() match, with entries in the installation record, to detect a prior version of a given package as installed. If these virtual packages don't preserve a history of releases, within their distribution manifest files, then mingw-get will not make an association for an upgrade of a previously installed version. This may not be a serious problem, but it will result in defunct clutter accumulating in the installation records. This is an issue I plan to address; perhaps it should be my next priority? > > I've used ".meta", > > rather than ".virtual", in my own trial manifests; I guess it > > would be good to agree a common standard here, but I've no > > particular preference for either one -- can we put it to a vote, > > please)? > > .meta is fine by me. Okay, shall we settle for .meta then? Any objections? Speak up now, before we publish the first of these, or forever hold your peace. > I believe the attached form the smallest possible consistent subset > with a closed dependency tree. I'll take a look, and have a play later. On a cursory glance, the set of package-lists seems more than strictly necessary, but there may be hidden dependencies I'm overlooking. -- Regards, Keith. |
From: Keith M. <kei...@us...> - 2010-07-02 20:07:03
Attachments:
msys.xml
msys-base.xml
|
On Tuesday 22 June 2010 16:46:14 Keith Marshall wrote: > > I believe the attached form the smallest possible consistent > > subset with a closed dependency tree. > > I'll take a look, and have a play later. On a cursory glance, the > set of package-lists seems more than strictly necessary, but there > may be hidden dependencies I'm overlooking. I've gone back to your original (long) list in msys.xml, then simply commented out all but those which I would consider to be the minimum sustainable subset; it reduces to the attached. Release of this will necessitate immediate and concurrent publication of: msys.xml.lzma msys-base.xml.lzma msys-bash.xml.lzma msys-core.xml.lzma msys-coreutils.xml.lzma msys-gettext.xml.lzma msys-libiconv.xml.lzma msys-regex.xml.lzma msys-termcap.xml.lzma However, there's a problem with this initial set, (or more explicitly, with the current formulation of msys-core.xml); it already requires msysCORE-1.0.15-1, which isn't available yet. Furthermore, I've found a problem with the dependency resolver: if I add a `lt' 1.0.15 requirement to msys-base, this will cause installation of 1.0.14, but it will not inhibit a parallel attempt to install 1.0.15, in response to the `ge *' requests from other packages :-( I always knew I was going to have to revisit that aspect of the dependency resolver, but I had hoped that it wouldn't need attention quite so soon; quickest work around will be to prune 1.0.15 out of msys-core.xml, unless you want to progress the 1.0.15 release immediately. Besides this, I do see a few redundant `requires' specs within the above set of manifests; they aren't really harmful, but they do incur unnecessary dependency resolver processing overhead. I've pruned them from my working set, so I'll propagate the changes to CVS, just as soon as I can find the time. -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2010-07-03 04:08:36
|
On 7/2/2010 10:35 AM, Keith Marshall wrote: > On Tuesday 22 June 2010 16:46:14 Keith Marshall wrote: >>> I believe the attached form the smallest possible consistent >>> subset with a closed dependency tree. >> >> I'll take a look, and have a play later. On a cursory glance, the >> set of package-lists seems more than strictly necessary, but there >> may be hidden dependencies I'm overlooking. Must be. I followed the dependency tree recursively starting only with msys-core, bash, and coreutils, and termcap. msys-base <requires ge="msys-core-*-msys-*-bin.tar" /> <requires ge="msys-bash-*-msys-*-bin.tar" /> <requires ge="msys-coreutils-*-msys-*-bin.tar" /> <requires ge="msys-termcap-*-msys-*-bin.tar" /> msys-core: (no reqs) msys-bash: <requires eq="msys-libtermcap-*-msys-*-dll-0.tar" /> <requires eq="msys-libregex-*-msys-*-dll-1.tar" /> <requires eq="msys-core-*-msys-*-bin.tar" /> <requires eq="msys-termcap-*-msys-*-bin.tar" /> msys-coreutils: <requires eq="msys-libintl-*-msys-*-dll-8.tar" /> <requires eq="msys-libiconv-*-msys-*-dll-2.tar" /> <requires eq="msys-libtermcap-*-msys-*-dll-0.tar" /> <requires eq="msys-core-*-msys-*-bin.tar" /> <requires eq="msys-termcap-*-msys-*-bin.tar" /> msys-termcap: no reqs So, new first-level deps, not already satisfied: msys-libtermcap-*-msys-*-dll-0 msys-libregex-*-msys-*-dll-1 msys-libintl-*-msys-*-dll-8 msys-libiconv-*-msys-*-dll-2 None of these have additional dependencies (not already satisfied by this list), so...transliterating -dll- to the appropriate .xml file, the whole list is... msys-bash.xml msys-core.xml msys-coreutils.xml msys-termcap.xml msys-gettext.xml (for libintl) msys-libiconv.xml msys-regex.xml So...why did I also include msys-expat, msys-gawk, msys-grep, and msys-sed? Well, if you look at the "new" xml's added by the first-round dependency check (basically to provide DLLs), you find that the NON-dll components in those same .xml's have additional dependencies. E.g. msys-gettext-dev pulls in <requires eq="msys-libexpat-*-msys-*-dll-1.tar" /> In fact, msys-core.xml specifies the msys-core-*-ext component and not just msys-core-*-bin. The -ext component has dependencies like: <requires eq="msys-grep-*-msys-*-bin.tar" /> <requires eq="msys-sed-*-msys-*-bin.tar" /> <requires eq="msys-gawk-*-msys-*-bin.tar" /> And there's your answer: a *completely* closed dependency tree -- without ripping out parts of the existing .xml files -- requires rather more simultaneously presented elements than one would like; even though "msys-gettext-dev" and "msys-core-ext" are hardly, themselves, "basic" components! > I've gone back to your original (long) list in msys.xml, then simply > commented out all but those which I would consider to be the minimum > sustainable subset; it reduces to the attached. Release of this will > necessitate immediate and concurrent publication of: > > msys.xml.lzma > msys-base.xml.lzma > msys-bash.xml.lzma > msys-core.xml.lzma did you delete the msys-core-*-ext section from msys-core.xml? If not, then you have dangling requires: specs on sed, grep, and gawk. > msys-coreutils.xml.lzma > msys-gettext.xml.lzma did you delete the msys-gettext-*-dev section from msys-gettext.xml? If not, then you have a dangling requires: spec on expat. > msys-libiconv.xml.lzma > msys-regex.xml.lzma > msys-termcap.xml.lzma > > However, there's a problem with this initial set, (or more explicitly, > with the current formulation of msys-core.xml); it already requires > msysCORE-1.0.15-1, which isn't available yet. Right. This is the whole discussion we had about scripts that are part of msys-core-*-1.0.14-bin and require sed, gawk, and grep. That's WHY 1.0.15 splits -bin into two separate packages, -bin and -ext, so we can avoid dependency loops like this. We really can't roll out even the basic msys installer without resolving that, and I think Cesar was waiting on the verdict vis. the msys DLL image base, before publishing 1.0.15. > Furthermore, I've > found a problem with the dependency resolver: if I add a `lt' 1.0.15 > requirement to msys-base, this will cause installation of 1.0.14, but > it will not inhibit a parallel attempt to install 1.0.15, in response > to the `ge *' requests from other packages :-( I always knew I was > going to have to revisit that aspect of the dependency resolver, but > I had hoped that it wouldn't need attention quite so soon; quickest > work around will be to prune 1.0.15 out of msys-core.xml, unless you > want to progress the 1.0.15 release immediately. I prefer the latter. The 1.0.14 packaging is fundamentally broken from a componentization/requirements-analysis perspective, unless we (a) lie about the tools that msys-core-1.0.14-bin actually has dependencies on -- that is, don't list the fact that it requires sed, grep, and awk, or (b) mingw-get can deal with dependency loops. > Besides this, I do see a few redundant `requires' specs within the > above set of manifests; they aren't really harmful, but they do incur > unnecessary dependency resolver processing overhead. Err...are you sure? I was pretty careful when drawing up those requirements. > I've pruned > them from my working set, so I'll propagate the changes to CVS, just > as soon as I can find the time. I'd rather you posted the patches here. I'm not saying my original commits were perfect -- of course they weren't -- but I'd like to know where I screwed up and have a chance to double check before any wholesale mods are committed. -- Chuck |
From: Keith M. <kei...@us...> - 2010-07-05 19:59:11
Attachments:
xml-20100703-1.diff
|
On Saturday 03 July 2010 05:08:14 Charles Wilson wrote: > On 7/2/2010 10:35 AM, Keith Marshall wrote: > > On Tuesday 22 June 2010 16:46:14 Keith Marshall wrote: > >>> I believe the attached form the smallest possible consistent > >>> subset with a closed dependency tree. > >> > >> I'll take a look, and have a play later. On a cursory glance, > >> the set of package-lists seems more than strictly necessary, but > >> there may be hidden dependencies I'm overlooking. > > Must be. I followed the dependency tree recursively starting only > with msys-core, bash, and coreutils, and termcap. > > [...snip...] > the whole list is... > > msys-bash.xml > msys-core.xml > msys-coreutils.xml > msys-termcap.xml > msys-gettext.xml (for libintl) > msys-libiconv.xml > msys-regex.xml Yep. Neglecting the top level msys.xml and msys-base.xml, this agrees with the minimum initial list I identified. > So...why did I also include msys-expat, msys-gawk, msys-grep, and > msys-sed? Well, if you look at the "new" xml's added by the > first-round dependency check (basically to provide DLLs), you find > that the NON-dll components in those same .xml's have additional > dependencies. [...snip...] > > And there's your answer: a *completely* closed dependency tree -- > without ripping out parts of the existing .xml files -- requires > rather more simultaneously presented elements than one would like; Agreed, the minimal list above doesn't represent a closed set; it is the set which is required to deliver a minimally functional shell environment, as a first step towards delivery of msys-base, but it does expose some initially unresolvable dependency references. I'm willing to live with that, to get things moving. > even though "msys-gettext-dev" and "msys-core-ext" are hardly, > themselves, "basic" components! msys-gettext-dev certainly isn't, (being a component of the system builder kit), but msys-core-ext might be considered so; it does provide part of the original base installation. Clearly, most users are also going to want awk, grep and sed, in addition to the coreutils and shell, so we should aim to progress them fairly quickly, to augment the initial subset. That just leaves expat, as the odd-ball among the extras you've identified. > > I've gone back to your original (long) list in msys.xml, then > > simply commented out all but those which I would consider to be > > the minimum sustainable subset; it reduces to the attached. > > Release of this will necessitate immediate and concurrent > > publication of: > > > > msys.xml.lzma > > msys-base.xml.lzma > > msys-bash.xml.lzma > > msys-core.xml.lzma > > did you delete the msys-core-*-ext section from msys-core.xml? No. > If not, then you have dangling requires: specs > on sed, grep, and gawk. Granted. I'd hope to address those as first priority, after an initial publication of the minimal set; given the delay which may accrue due to non-availability of msysCORE-1.0.15 (see below), it may even be the case that these could also be ready for inclusion in the initial roll-out. > > msys-coreutils.xml.lzma > > msys-gettext.xml.lzma > > did you delete the msys-gettext-*-dev section from > msys-gettext.xml? If not, then you have a dangling requires: spec > on expat. Yes. I can live with that, until we're ready to support delivery of the MSYS system development kit via mingw-get. Alternatively, for the sake of one additional XML file, if you feel more comfortable closing that dependency gap up front, I'm amenable to that too. > > msys-libiconv.xml.lzma > > msys-regex.xml.lzma > > msys-termcap.xml.lzma > > > > However, there's a problem with this initial set, (or more > > explicitly, with the current formulation of msys-core.xml); it > > already requires msysCORE-1.0.15-1, which isn't available yet. > > Right. This is the whole discussion we had about scripts that are > part of msys-core-*-1.0.14-bin and require sed, gawk, and grep. > That's WHY 1.0.15 splits -bin into two separate packages, -bin and > -ext, so we can avoid dependency loops like this. True, but msys-base should ultimately require msys-core-ext anyway, so having added manifests to satisfy the awk, grep and sed dependencies, we could just as easily deliver a functional msys-base derived from the existing msysCORE-1.0.14 backbone. > We really can't roll out even the basic msys installer without > resolving that, and I think Cesar was waiting on the verdict vis. > the msys DLL image base, before publishing 1.0.15. That's reasonable, but I don't think it's imperative for an early progression towards msys-base via mingw-get. > > Furthermore, I've > > found a problem with the dependency resolver: if I add a `lt' > > 1.0.15 requirement to msys-base, this will cause installation of > > 1.0.14, but it will not inhibit a parallel attempt to install > > 1.0.15, in response to the `ge *' requests from other packages > > :-( I always knew I was going to have to revisit that aspect of > > the dependency resolver, but I had hoped that it wouldn't need > > attention quite so soon; quickest work around will be to prune > > 1.0.15 out of msys-core.xml, unless you want to progress the > > 1.0.15 release immediately. > > I prefer the latter. Okay; then getting msysCORE-1.0.15 out the door needs to be given urgent priority. As noted above, I don't entirely agree, but if you and Cesar prefer to play it that way, then please deliver. > The 1.0.14 packaging is fundamentally broken from a > componentization/requirements-analysis perspective, unless we (a) > lie about the tools that msys-core-1.0.14-bin actually has > dependencies on -- that is, don't list the fact that it requires > sed, grep, and awk, or (b) mingw-get can deal with dependency > loops. I believe it can, with one exception: a component must not directly depend on itself, (that runs away into a stack overflow). However, I would prefer not to rely on it. > > Besides this, I do see a few redundant `requires' specs within > > the above set of manifests; they aren't really harmful, but they > > do incur unnecessary dependency resolver processing overhead. > > Err...are you sure? I was pretty careful when drawing up those > requirements. Yes, I'm sure. Consider this snippet, from your msys-bash.xml: <component class="bin"> <release tarname="bash-3.1.17-2-msys-1.0.11-bin.tar.lzma" /> <release tarname="bash-3.1.17-3-msys-1.0.13-bin.tar.lzma" > <requires eq="msys-libtermcap-*-msys-*-dll-0.tar" /> <requires eq="msys-libregex-*-msys-*-dll-1.tar" /> </release> <requires eq="msys-core-*-msys-*-bin.tar" /> <requires eq="msys-termcap-*-msys-*-bin.tar" /> </component> Here, in the case of bash-3.1.17-3, I see no fewer than *three* separate references to msys-core-*-msys-*-bin.tar, one direct, and two implicit in each of the two DLL references. This isn't wrong, but it isn't optimal. There isn't much we can do about the two implicit references -- it would be wrong to deny the dependency in either of the DLL manifests -- but, knowing that it is implicit in any DLL reference, we can avoid the direct reference: <component class="bin"> <release tarname="bash-3.1.17-2-msys-1.0.11-bin.tar.lzma"> <requires eq="msys-core-*-msys-*-bin.tar" /> </release> <release tarname="bash-3.1.17-3-msys-1.0.13-bin.tar.lzma"> <requires eq="msys-libtermcap-*-msys-*-dll-0.tar" /> <requires eq="msys-libregex-*-msys-*-dll-1.tar" /> </release> <requires eq="msys-termcap-*-msys-*-bin.tar" /> </component> Furthermore, should msys-libtermcap-dll-0 not itself depend on msys-termcap-%-msys-%-bin.tar? (It doesn't in its manifest, as you've written it, but logically, I think perhaps that it should). If that is so, then we can also eliminate the direct reference: <component class="bin"> <release tarname="bash-3.1.17-2-msys-1.0.11-bin.tar.lzma"> <requires eq="msys-core-*-msys-*-bin.tar" /> <requires eq="msys-termcap-*-msys-*-bin.tar" /> </release> <release tarname="bash-3.1.17-3-msys-1.0.13-bin.tar.lzma"> <requires eq="msys-libtermcap-*-msys-*-dll-0.tar" /> <requires eq="msys-libregex-*-msys-*-dll-1.tar" /> </release> </component> Applying the same analysis to msys-base.xml: <requires ge="msys-core-*-msys-*-bin.tar" /> <requires ge="msys-bash-*-msys-*-bin.tar" /> <requires ge="msys-coreutils-*-msys-*-bin.tar" /> <requires ge="msys-termcap-*-msys-*-bin.tar" /> This includes redundant references to msys-core-*-msys-*-bin.tar and to msys-termcap-*-msys-*-bin.tar, because both are already implicitly encapsulated by msys-bash-bin; there is no need to explicitly include them, as direct requirements of msys-base, so the above list of four may be safely reduced to just the pair: <requires ge="msys-bash-*-msys-*-bin.tar" /> <requires ge="msys-coreutils-*-msys-*-bin.tar" /> > > I've pruned > > them from my working set, so I'll propagate the changes to CVS, > > just as soon as I can find the time. > > I'd rather you posted the patches here. I'm not saying my original > commits were perfect -- of course they weren't -- but I'd like to > know where I screwed up and have a chance to double check before > any wholesale mods are committed. Okay, I'll do that. I've attached a patch for msys-bash.xml and msys-termcap.xml, addressing the redundancies identified above; (the msys-termcap.xml patch is incomplete, since I neglected to address a further redundancy within its dev component, introduced by the patch itself, and I don't have an internet connection right now, so I'm not able to regenerate it. -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2010-07-05 22:47:44
|
On 7/5/2010 8:32 AM, Keith Marshall wrote: > Yep. Neglecting the top level msys.xml and msys-base.xml, this agrees > with the minimum initial list I identified. > >> >> And there's your answer: a *completely* closed dependency tree -- >> without ripping out parts of the existing .xml files -- requires >> rather more simultaneously presented elements than one would like; > > Agreed, the minimal list above doesn't represent a closed set; it is > the set which is required to deliver a minimally functional shell > environment, as a first step towards delivery of msys-base, but it > does expose some initially unresolvable dependency references. I'm > willing to live with that, to get things moving. OK. I'm used to cygwin's 'upset' script that marshalls the setup.hint components into a single setup.ini; if there are any unmet dependencies it whines loudly and fails. If mingw-get is ok with a not-completely-closed dependency tree, then so am I -- provided it doesn't stay that way very long. > msys-gettext-dev certainly isn't, (being a component of the system > builder kit), but msys-core-ext might be considered so; it does > provide part of the original base installation. Ack. > Clearly, most users are also going to want awk, grep and sed, in > addition to the coreutils and shell, so we should aim to progress > them fairly quickly, to augment the initial subset. That just leaves > expat, as the odd-ball among the extras you've identified. OK. >> If not, then you have dangling requires: specs >> on sed, grep, and gawk. > > Granted. I'd hope to address those as first priority, after an > initial publication of the minimal set; given the delay which may > accrue due to non-availability of msysCORE-1.0.15 (see below), it may > even be the case that these could also be ready for inclusion in the > initial roll-out. I see. >> did you delete the msys-gettext-*-dev section from >> msys-gettext.xml? If not, then you have a dangling requires: spec >> on expat. > > Yes. I can live with that, until we're ready to support delivery of > the MSYS system development kit via mingw-get. Alternatively, for > the sake of one additional XML file, if you feel more comfortable > closing that dependency gap up front, I'm amenable to that too. Faster is better. If we could roll it out tomorrow -- gaps or not -- I'd be in favor. >> Right. This is the whole discussion we had about scripts that are >> part of msys-core-*-1.0.14-bin and require sed, gawk, and grep. >> That's WHY 1.0.15 splits -bin into two separate packages, -bin and >> -ext, so we can avoid dependency loops like this. > > True, but msys-base should ultimately require msys-core-ext anyway, so > having added manifests to satisfy the awk, grep and sed dependencies, > we could just as easily deliver a functional msys-base derived from > the existing msysCORE-1.0.14 backbone. Hmm... If Cesar is unavailable, I could "split" msyscore-1.0.14-1-bin *manually* into msyscore-1.0.14-2-{bin|ext}, and *manually* rebase msys-1.0.dll to 0x60800000 (if that's what we choose). Then, we could use that in the current .xml files and not need as much of a rush for the "official" msys-1.0.15. Also, I could roll out an urgent 1.0.15-1 using Cesar's scripts, but I don't want to step on his toes unless it's an emergency. Your call. > That's reasonable, but I don't think it's imperative for an early > progression towards msys-base via mingw-get. > >>> I always knew I was going to have to revisit that aspect of >>> the dependency resolver, but I had hoped that it wouldn't need >>> attention quite so soon; quickest work around will be to prune >>> 1.0.15 out of msys-core.xml, unless you want to progress the >>> 1.0.15 release immediately. >> >> I prefer the latter. > > Okay; then getting msysCORE-1.0.15 out the door needs to be given > urgent priority. As noted above, I don't entirely agree, but if you > and Cesar prefer to play it that way, then please deliver. I've noted some options, above. > I believe it can, with one exception: a component must not directly > depend on itself, (that runs away into a stack overflow). However, I > would prefer not to rely on it. Agreed. > >>> Besides this, I do see a few redundant `requires' specs within >>> the above set of manifests; they aren't really harmful, but they >>> do incur unnecessary dependency resolver processing overhead. >> >> Err...are you sure? I was pretty careful when drawing up those >> requirements. > > Yes, I'm sure. Ah. All of your examples appear to be "redundancies" related to explicit dependencies and implicit ones. First, I disagree that these are "redundant". Take bash.exe: it calls open() -- a symbol satisfied by a direct dependency on msys-1.0.dll. Therefore, it directly depends on msys-core-*-bin. However, bash.exe as compiled ALSO depends directly on msys-intl-8.dll (e.g. msys-libintl-*-dll-8), and msys-intl-8.dll depends directly on msys-1.0.dll. It is my contention that msys-bash.xml should list both of its direct dependencies, msys-core-bin and msys-libintl-*-dll-8, without regard to the "hidden" dependencies listed for pkg msys-libintl. I mean, you're trying to get humans to prune direct dependencies based on the chain of OTHER dependencies, whose exact deptree is subject to change! This is NOT a job for humans; it is EXACTLY the job for a computer. > Consider this snippet, from your msys-bash.xml: > > <component class="bin"> > <release tarname="bash-3.1.17-2-msys-1.0.11-bin.tar.lzma" /> > <release tarname="bash-3.1.17-3-msys-1.0.13-bin.tar.lzma" > > <requires eq="msys-libtermcap-*-msys-*-dll-0.tar" /> > <requires eq="msys-libregex-*-msys-*-dll-1.tar" /> > </release> > <requires eq="msys-core-*-msys-*-bin.tar" /> > <requires eq="msys-termcap-*-msys-*-bin.tar" /> > </component> > > Here, in the case of bash-3.1.17-3, I see no fewer than *three* > separate references to msys-core-*-msys-*-bin.tar, one direct, and > two implicit in each of the two DLL references. This isn't wrong, > but it isn't optimal. I disagree. I don't think it's our job to twist into pretzels parsing deep dependency chains (or shallow ones!) to make life easy for a computer program that is much better than we are at sorting all that stuff out. Let it. > There isn't much we can do about the two > implicit references -- it would be wrong to deny the dependency in > either of the DLL manifests -- but, knowing that it is implicit in > any DLL reference, we can avoid the direct reference: > > <component class="bin"> > <release tarname="bash-3.1.17-2-msys-1.0.11-bin.tar.lzma"> > <requires eq="msys-core-*-msys-*-bin.tar" /> > </release> > <release tarname="bash-3.1.17-3-msys-1.0.13-bin.tar.lzma"> > <requires eq="msys-libtermcap-*-msys-*-dll-0.tar" /> > <requires eq="msys-libregex-*-msys-*-dll-1.tar" /> > </release> > <requires eq="msys-termcap-*-msys-*-bin.tar" /> > </component> Rule: if I depend on any msys dll, then I don't have to list msys-1.0.dll (aka msys-core-*-bin) even though I DO depend on it. BUT, if I don't depend on any msys dll other than msys-1.0.dll, then I MUST list msys-core-*-bin in my dependency chain. Sorry, that seems prone to breakage. How about: Rule: list all DIRECT dependencies. Do not list transitive dependencies. Let mingw-get sort it all out; that's what it is for. > Furthermore, should msys-libtermcap-dll-0 not itself depend on > msys-termcap-%-msys-%-bin.tar? (It doesn't in its manifest, as > you've written it, but logically, I think perhaps that it should). > If that is so, then we can also eliminate the direct reference: Usually, a -bin package will include exe's that depend on the dll, so the usual direction is that the -bin package depends on the dll package. However, in this case the "bin" package consists only of a data file, /etc/termcap. Now, termcap functions (in the DLL) will operate without a termcap database; but it is not optimal. Since it wasn't ABSOLUTELY necessary, I didn't add that (odd, backwards?) dependency that would make the termcap dll package "depend" on the termcap bin package. But on this, I could go either way. > <component class="bin"> > <release tarname="bash-3.1.17-2-msys-1.0.11-bin.tar.lzma"> > <requires eq="msys-core-*-msys-*-bin.tar" /> > <requires eq="msys-termcap-*-msys-*-bin.tar" /> > </release> > <release tarname="bash-3.1.17-3-msys-1.0.13-bin.tar.lzma"> > <requires eq="msys-libtermcap-*-msys-*-dll-0.tar" /> > <requires eq="msys-libregex-*-msys-*-dll-1.tar" /> > </release> > </component> > > Applying the same analysis to msys-base.xml: > > <requires ge="msys-core-*-msys-*-bin.tar" /> > <requires ge="msys-bash-*-msys-*-bin.tar" /> > <requires ge="msys-coreutils-*-msys-*-bin.tar" /> > <requires ge="msys-termcap-*-msys-*-bin.tar" /> > > This includes redundant references to msys-core-*-msys-*-bin.tar and > to msys-termcap-*-msys-*-bin.tar, because both are already implicitly > encapsulated by msys-bash-bin; there is no need to explicitly include > them, as direct requirements of msys-base, so the above list of four > may be safely reduced to just the pair: > > <requires ge="msys-bash-*-msys-*-bin.tar" /> > <requires ge="msys-coreutils-*-msys-*-bin.tar" /> Again, you're making me, the human, parse a chain of indirect dependencies -- an operation prone to both error and CHANGE in the future -- in order to save a few hundred clock cycles of mingw-get's time. This is not the path of wisdom, IMO. >> I'd rather you posted the patches here. I'm not saying my original >> commits were perfect -- of course they weren't -- but I'd like to >> know where I screwed up and have a chance to double check before >> any wholesale mods are committed. > > Okay, I'll do that. I've attached a patch for msys-bash.xml and > msys-termcap.xml, addressing the redundancies identified above; (the > msys-termcap.xml patch is incomplete, since I neglected to address a > further redundancy within its dev component, introduced by the patch > itself, and I don't have an internet connection right now, so I'm > not able to regenerate it. Thanks for posting the patch, but I disagree with the premise on which it was generated. I think this needs more discussion. -- Chuck |
From: Keith M. <kei...@us...> - 2010-07-06 19:52:50
|
On Monday 05 July 2010 23:47:00 Charles Wilson wrote: > If mingw-get is ok with a not-completely-closed dependency tree, It is. > then so am I -- provided it doesn't stay that way very long. Agreed. > > > you have a dangling requires: spec on expat. > > > > Yes. I can live with that, until we're ready to support delivery > > of the MSYS system development kit via mingw-get. Alternatively, > > for the sake of one additional XML file, if you feel more > > comfortable closing that dependency gap up front, I'm amenable to > > that too. > > Faster is better. If we could roll it out tomorrow -- gaps or not > -- I'd be in favor. That's my opinion too. > Ah. All of your examples appear to be "redundancies" related to > explicit dependencies and implicit ones. > > First, I disagree that these are "redundant". Take bash.exe: it > calls open() -- a symbol satisfied by a direct dependency on > msys-1.0.dll. Therefore, it directly depends on msys-core-*-bin. > However, bash.exe as compiled ALSO depends directly on > msys-intl-8.dll (e.g. > msys-libintl-*-dll-8), and msys-intl-8.dll depends directly on > msys-1.0.dll. > > It is my contention that msys-bash.xml should list both of its > direct dependencies, msys-core-bin and msys-libintl-*-dll-8, > without regard to the "hidden" dependencies listed for pkg > msys-libintl. > > I mean, you're trying to get humans to prune direct dependencies > based on the chain of OTHER dependencies, whose exact deptree is > subject to change! Well, I'm not demanding it; I'm merely suggesting it. > This is NOT a job for humans; it is EXACTLY the > job for a computer. Maybe I've spent too much time writing assembly code, (where the [human] programmer is normally expected to prune out unnecessary code). Certainly, it is better to overspecify than to underspecify; in case of doubt, yes, you must leave it in; if you can be certain that it is redundant, (due to a hidden dependency known to you), you may exercise your judgement, and leave it out -- THAT's something humans are much better equipped for than are computers. > > Furthermore, should msys-libtermcap-dll-0 not itself depend on > > msys-termcap-%-msys-%-bin.tar? (It doesn't in its manifest, as > > you've written it, but logically, I think perhaps that it > > should). If that is so, then we can also eliminate the direct > > reference: > > Usually, a -bin package will include exe's that depend on the dll, > so the usual direction is that the -bin package depends on the dll > package. However, in this case the "bin" package consists only of a > data file, /etc/termcap. Now, termcap functions (in the DLL) will > operate without a termcap database; but it is not optimal. So IIUC, libtermcap has built-in default settings which may then be augmented by the external database, when present; that's more-or-less what I expected. Thanks for the confirmation. > Since it wasn't ABSOLUTELY necessary, I didn't add that (odd, > backwards?) dependency that would make the termcap dll package > "depend" on the termcap bin package. But on this, I could go either > way. Even if not absolutely necessary, it does make sense, (at least to me); I would be inclined to add it. Whether or not it also makes sense to then remove the direct dependency of the dev package on the bin is a local optimisation dictated by human judgement; since it is local, I would be inclined to also do that, but it is down to your personal choice -- this *isn't* a requirement. > > Applying the same analysis to msys-base.xml: > > > > <requires ge="msys-core-*-msys-*-bin.tar" /> > > <requires ge="msys-bash-*-msys-*-bin.tar" /> > > <requires ge="msys-coreutils-*-msys-*-bin.tar" /> > > <requires ge="msys-termcap-*-msys-*-bin.tar" /> > > > > This includes redundant references to msys-core-*-msys-*-bin.tar > > and to msys-termcap-*-msys-*-bin.tar, because both are already > > implicitly encapsulated by msys-bash-bin; there is no need to > > explicitly include them, as direct requirements of msys-base, so > > the above list of four may be safely reduced to just the pair: > > > > <requires ge="msys-bash-*-msys-*-bin.tar" /> > > <requires ge="msys-coreutils-*-msys-*-bin.tar" /> > > Again, you're making me, the human, parse a chain of indirect > dependencies -- an operation prone to both error and CHANGE in the > future -- in order to save a few hundred clock cycles of > mingw-get's time. Sorry, in this case I cannot agree; by your own argument, neither of the two dependencies I've removed belong here. Go back to basics. As a human, I want to install a minimal shell environment. Do I think, "okay I'll install msys-core-bin"? (Oh! That's nice! Now what the heck do I *do* with it?) No, I'm much more likely to go straight to msys-bash-bin, and leave mingw-get to identify that it has dependencies on msys-core-bin and msys-termcap-bin, (which I'm also unlikely to consider installing in isolation). In this case, it is you who are asking the human to add hidden dependencies, (based solely on your human knowledge); these *really* should be left to mingw-get to resolve indirectly. -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2010-07-07 06:12:41
|
On 7/6/2010 7:07 AM, Keith Marshall wrote: > On Monday 05 July 2010 23:47:00 Charles Wilson wrote: >> It is my contention that msys-bash.xml should list both of its >> direct dependencies, msys-core-bin and msys-libintl-*-dll-8, >> without regard to the "hidden" dependencies listed for pkg >> msys-libintl. >> >> I mean, you're trying to get humans to prune direct dependencies >> based on the chain of OTHER dependencies, whose exact deptree is >> subject to change! > > Well, I'm not demanding it; I'm merely suggesting it. > >> This is NOT a job for humans; it is EXACTLY the >> job for a computer. > > Maybe I've spent too much time writing assembly code, (where the > [human] programmer is normally expected to prune out unnecessary > code). Well, yeah -- when every byte counts, and the software will be embedded in 127 million widgets, the calculus of the cost of developer time vs. runtime/space is very different. > Certainly, it is better to overspecify than to underspecify; > in case of doubt, yes, you must leave it in; if you can be certain > that it is redundant, (due to a hidden dependency known to you), you > may exercise your judgement, and leave it out -- THAT's something > humans are much better equipped for than are computers. Well, you assume quite a bit. :-) With enough iterations and effort, we can probably prune the dep tree accurately to form the minimum chain *as the packages exist today*. I'm worried about hidden-hand effects. Suppose A-bin depends directly, itself, on B-dll-0 AND C-dll-0, but B-dll-0 also happens to depend C-dll-0. I'm smart, I know this, so I prune the requirements list for A-bin to specify only B-dll-0. Let's further assume that E-bin depends only on B-dll-0, and not on C-dll. So, Alice installs A-bin and E-bin, and gets B-dll-0 and C-dll-0 automatically, and she is happy. And then, next Tuesday, Bob uploads a new version of B-dll-0 that is compiled so that it uses D-dll-0 instead (or, maybe, C-dll-1). However, the public ABI of B-dll *itself* has not changed; so it is still B-dll-0. Well, this new version of B-dll-0 has a different requires: list. So, after next Tuesday, Charlene installs A-bin and E-bin, and gets B-dll-0 and D-dll-0 (or maybe C-dll-1) installed automatically. However, she does NOT get C-dll-0, and that is a direct dependency of A-bin. E-bin has all of its dependencies met, so it runs, but: A-bin doesn't run, and Charlene is not happy. All because I tried to be smart, and prune direct dependencies of A-bin based on what I knew -- then -- about all 200 other packages. And because Bob did not somehow magically deduce that A-bin *really* had a hidden dependency on C-dll-0 that was "picked up" by the dependency on B-dll-0, and that he should have modified A-bin.xml as part of uploading the new version of B-dll-0 and updating B-dll.xml. Err...except HOW would Bob ever have known that? Better to be explicit than smart, IMO. >> Now, termcap functions (in the DLL) will >> operate without a termcap database; but it is not optimal. > > So IIUC, libtermcap has built-in default settings which may then be > augmented by the external database, when present; that's more-or-less > what I expected. Thanks for the confirmation. That's my understanding. The default is pretty dumb, tho: 'dumb' terminal. >> Since it wasn't ABSOLUTELY necessary, I didn't add that (odd, >> backwards?) dependency that would make the termcap dll package >> "depend" on the termcap bin package. But on this, I could go either >> way. > > Even if not absolutely necessary, it does make sense, (at least to > me); I would be inclined to add it. Whether or not it also makes > sense to then remove the direct dependency of the dev package on the > bin is a local optimisation dictated by human judgement; since it is > local, I would be inclined to also do that, but it is down to your > personal choice -- this *isn't* a requirement. I don't mind it the way you have it the collection you posted on 7/6/2010 at 11:21 AM EDT, where msys-termcap-dll-0 depends on msys-termcap-bin, and msys-termcap-bin is removed from all requires. Nobody would ever have a direct dependence on /etc/termcap aka msys-termcap-bin; it really is a *completely* internal detail of msys-termcap-dll-0. >>> Applying the same analysis to msys-base.xml: >> >> Again, you're making me, the human, parse a chain of indirect >> dependencies -- an operation prone to both error and CHANGE in the >> future -- in order to save a few hundred clock cycles of >> mingw-get's time. > > Sorry, in this case I cannot agree; by your own argument, neither of > the two dependencies I've removed belong here. Oh, I see what you're getting at with respect to msys-base.xml. More below. > Go back to basics. > As a human, I want to install a minimal shell environment. ... > In this case, it > is you who are asking the human to add hidden dependencies, (based > solely on your human knowledge); these *really* should be left to > mingw-get to resolve indirectly. You're right, IF you were to follow the rules I specified for msys-base, then yes, the stripped down minimal msys-base we currently have would spec only the two pkgs you have listed. But...I was treating msys-base.xml a little differently, since it is the "experimental meta-package" we're talking about slowly beefing up to imitate-monolithic-installer-footprint status from its current bare bones version. I wanted it to be very very explicitly about EXACTLY what packages it would install -- so we humans could tell at a glance exactly which .xml's we needed to finalize (from the stripped down version, you can't tell directly that 'oh yeah, I need to make sure that msys-termcap.xml is correct or this won't work'). So, yeah, I was doing all of that manual .xml requirements parsing I complained about -- but only for msys-base.xml, and for a specific temporary reason. My idea was that once we did get everything squared away and msys-base brought up to standard, THEN we'd go back and trim out the 'pulled in automatically' stuff. But if you want to approach the msys-base.xml using the same rules as all the other .xmls, that's okay by me. -- Chuck |
From: Cesar S. <ces...@gm...> - 2010-07-06 00:06:44
|
On 5/7/2010 09:32, Keith Marshall wrote: > On Saturday 03 July 2010 05:08:14 Charles Wilson wrote: >>> Furthermore, I've >>> found a problem with the dependency resolver: if I add a `lt' >>> 1.0.15 requirement to msys-base, this will cause installation of >>> 1.0.14, but it will not inhibit a parallel attempt to install >>> 1.0.15, in response to the `ge *' requests from other packages >>> :-( I always knew I was going to have to revisit that aspect of >>> the dependency resolver, but I had hoped that it wouldn't need >>> attention quite so soon; quickest work around will be to prune >>> 1.0.15 out of msys-core.xml, unless you want to progress the >>> 1.0.15 release immediately. >> >> I prefer the latter. > > Okay; then getting msysCORE-1.0.15 out the door needs to be given > urgent priority. As noted above, I don't entirely agree, but if you > and Cesar prefer to play it that way, then please deliver. > I have been a bit short on free time lately, but I think I can manage. I'll work on it presently. Regards, Cesar |
From: Cesar S. <ces...@gm...> - 2010-07-06 03:19:40
|
On 5/7/2010 21:06, Cesar Strauss wrote: > On 5/7/2010 09:32, Keith Marshall wrote: >> Okay; then getting msysCORE-1.0.15 out the door needs to be given >> urgent priority. As noted above, I don't entirely agree, but if you >> and Cesar prefer to play it that way, then please deliver. >> > > I have been a bit short on free time lately, but I think I can manage. > I'll work on it presently. > I believe it will be ready by tomorrow. The new MSYS DLL base address is 0x60800000. Here is how the package is split: msysCORE-1.0.15-1-msys-1.0.15-bin.tar.lzma bin/msys-1.0.dll bin/msysmnt.exe bin/ps.exe etc/fstab.sample etc/inputrc.default etc/profile m.ico msys.ico msysCORE-1.0.15-1-msys-1.0.15-ext.tar.lzma bin/cls bin/clsb bin/cmd bin/ftp bin/lnkcnv bin/mount bin/msysinfo bin/start bin/umount bin/which postinstall/pi.bat postinstall/pi.sh msys.bat msysCORE-1.0.15-1-msys-1.0.15-dev.tar.lzma include/* lib/* msysCORE-1.0.15-1-msys-1.0.15-doc.tar.lzma share/doc/MSYS/MSYS_MISSION share/doc/MSYS/MSYS_VS_CYGWIN share/doc/MSYS/MSYS_WELCOME.rtf share/doc/MSYS/README.rtf msysCORE-1.0.15-1-msys-1.0.15-lic.tar.lzma share/doc/MSYS/COPYING share/doc/MSYS/COPYING.LIB share/doc/MSYS/CYGWIN_LICENSE share/doc/MSYS/MSYS_LICENSE.rtf msysCORE-1.0.15-1-msys-1.0.15-dbg.tar.lzma bin/msys-1.0-debug.dll bin/msys-1.0.dll.dbg bin/strace.exe I did manage to update my build environment with Chuck's latest releases. Regards, Cesar |
From: Charles W. <cwi...@us...> - 2010-07-06 04:00:52
|
On 7/5/2010 11:19 PM, Cesar Strauss wrote: > I believe it will be ready by tomorrow. Thanks for taking care of this! > The new MSYS DLL base address is 0x60800000. That should probably work. > Here is how the package is split: Looks fine to me. -- Chuck |
From: Keith M. <kei...@us...> - 2010-07-06 19:52:44
|
On Tuesday 06 July 2010 05:00:12 Charles Wilson wrote: > On 7/5/2010 11:19 PM, Cesar Strauss wrote: > > I believe it will be ready by tomorrow. > > Thanks for taking care of this! Seconded! > > The new MSYS DLL base address is 0x60800000. > > That should probably work. Works for me, (in that I've actually tested it on a fresh install, where I've confirmed that the old 0x71000000 base address causes a reproducible failure, which rebasing to 0x60800000 circumvents). > > Here is how the package is split: > > Looks fine to me. And to me. One other trivial issue you may wish to look at, (or not if you prefer): in /bin/cmd these `echo $COMSPEC | sed -e 's#\\\\#/#g'` "$@" shenanigans are unnecessary, (and may fail if, heaven forfend, the COMSPEC path should ever include white space). "$COMSPEC" "$@" is quite sufficient. -- Regards, Keith. |
From: Keith M. <kei...@us...> - 2010-07-06 19:52:58
Attachments:
msys-package-list.xml.tar.gz
msys-package-list.md5
|
On Tuesday 06 July 2010 04:19:22 Cesar Strauss wrote: > >> Okay; then getting msysCORE-1.0.15 out the door needs to be > >> given urgent priority. As noted above, I don't entirely agree, > >> but if you and Cesar prefer to play it that way, then please > >> deliver. > > > > I have been a bit short on free time lately, No problem. I'd guessed that was probably the case; you have been a bit quiet of late. > > but I think I can > > manage. I'll work on it presently. > > I believe it will be ready by tomorrow. Excellent! > The new MSYS DLL base address is 0x60800000. > > Here is how the package is split: > > msysCORE-1.0.15-1-msys-1.0.15-bin.tar.lzma > bin/msys-1.0.dll > bin/msysmnt.exe > bin/ps.exe > etc/fstab.sample > etc/inputrc.default > etc/profile > m.ico > msys.ico FWIW, I've extracted msysCORE-1.0.14-1-msys-1.0.14-bin.tar.lzma to a temporary staging directory, deleted all but the above from the tree, rebased bin/msys-1.0.dll to 0x60800000, and repackaged the resulting tree as a local msysCORE-1.0.15-1-msys-1.0.15-bin.tar.lzma, and put that into my local mingw-get package cache. With the cache otherwise empty, and with the attached set of tentative XML manifests, starting with a completely empty (non-existent) MSYS sysroot directory mingw-get install msys-base results in a minimal, but entirely functional shell environment, and the cache ultimately populated with the packages listed in the md5 sum file, also attached. -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2010-07-06 20:52:47
|
On 7/6/2010 11:21 AM, Keith Marshall wrote: > FWIW, I've extracted msysCORE-1.0.14-1-msys-1.0.14-bin.tar.lzma to a > temporary staging directory, deleted all but the above from the tree, > rebased bin/msys-1.0.dll to 0x60800000, and repackaged the resulting > tree as a local msysCORE-1.0.15-1-msys-1.0.15-bin.tar.lzma, and put > that into my local mingw-get package cache. With the cache otherwise > empty, and with the attached set of tentative XML manifests, starting > with a completely empty (non-existent) MSYS sysroot directory > > mingw-get install msys-base > > results in a minimal, but entirely functional shell environment, and > the cache ultimately populated with the packages listed in the md5 > sum file, also attached. Excellent. I don't have time to inspect the attachments or respond to your other (7:07 am EDT) message; will do that later tonight. -- Chuck |
From: Charles W. <cwi...@us...> - 2010-07-07 06:17:57
|
On 7/6/2010 11:21 AM, Keith Marshall wrote: > FWIW, I've extracted msysCORE-1.0.14-1-msys-1.0.14-bin.tar.lzma to a > temporary staging directory, deleted all but the above from the tree, > rebased bin/msys-1.0.dll to 0x60800000, and repackaged the resulting > tree as a local msysCORE-1.0.15-1-msys-1.0.15-bin.tar.lzma, and put > that into my local mingw-get package cache. With the cache otherwise > empty, and with the attached set of tentative XML manifests, starting > with a completely empty (non-existent) MSYS sysroot directory > > mingw-get install msys-base > > results in a minimal, but entirely functional shell environment, and > the cache ultimately populated with the packages listed in the md5 > sum file, also attached. General comment: man, we gotta get rid of the whole TAB-vs-SPACE thing. Ditto for CRLF-vs-LF... (I vote no tabs ever; always LF). msys-coreutils: ================================ <component class="ext"> - <release tarname="coreutils-5.97-2-msys-1.0.11-ext.tar.lzma" /> - <release tarname="coreutils-5.97-3-msys-1.0.13-ext.tar.lzma" > - <requires eq="msys-libintl-*-msys-*-dll-8.tar" /> - </release> - <requires eq="msys-core-*-msys-*-bin.tar" /> <requires eq="msys-coreutils-%-msys-%-bin.tar" /> + <release tarname="coreutils-5.97-2-msys-1.0.11-ext.tar.lzma" /> + <release tarname="coreutils-5.97-3-msys-1.0.13-ext.tar.lzma" /> </component> Why this change, for 1.0.13-ext? It does contain executables that depend directly on msys-intl-8.dll (and natch, on msys-1.0.dll). Are you relying on the transitive requirement chain coreutils-5.97-3-msys-1.0.13-ext --> coreutils-%-msys-%-ext --> msys-libintl-*-msys-*-dll-8 --> msys-core-*-bin ? Subject to our conversion in the other subthread of this conversation, I don't think you should do that. msys-core: ================================ First, do all of these releases need to use the construction: <release tarname="msys-core-1.0.15-1-msys-1.0.15-bin.tar.lzma" > <download tarname=msysCORE-1.0.15-1-msys-1.0.15-bin.tar.lzma"/> </release> rather than <release tarname="msysCORE-1.0.15-1-msys-1.0.15-bin.tar.lzma"/> If not, why not (what am I forgetting?) Second, while I assumed (and the comments in the .xml file state) that the license file and documentation lives in the msys-core-bin package, Cesar's latest release split those into separate -doc and -lic packages. So, this .xml needs a lot of modification; also, this makes the <license /> tag a little hard to manage to be accurate for both <= 1.0.14 and >= 1.0.15. Maybe we should cut bait instead of fish, and -- at least for the msys-core.xml file -- specify ONLY 1.0.15 and newer, and don't include any information regarding 1.0.14 and older. Third, - <requires eq="msys-coreutils-*-msys-*-bin.tar" /> + <!-- update this once the appropriate .xml files exist <requires eq="msys-bash-*-msys-*-bin.tar" /> - <requires eq="msys-grep-*-msys-*-bin.tar" /> - <requires eq="msys-sed-*-msys-*-bin.tar" /> <requires eq="msys-gawk-*-msys-*-bin.tar" /> + ... + --> I can see commenting out or removing references to the xml files that haven't yet been validated. But why put msys-bash-bin inside that comment block? msys-bash.xml we have, and it is (in the process of being) validated...msys-coreutils-ext contains a script /bin/groups, that script require bash, msys-bash.xml is ready, ergo...require it. Also, that script ALSO calls an application in msys-coreutils-bin (e.g. '/bin/groups' needs 'id.exe') so msys-coreutils-ext has a direct dependency on msys-coreutils-bin. So, it should be listed even in our temporarily abbreviated requires list. msys-gettext: ================================ msys-gettext-dev does too require msys-core-bin (Pbbbbbt!), because it has exe's that directly depend on msys-1.0.dll itself. Ditto msys-gettext-bin. Otherwise, you're relying on the transitive requires thru the various OTHER dll packages, to ensure that msys-1.0.dll gets installed. Probably a VERY safe bet, but... All of the others seem fine. Thanks for your diligence on this, Keith. -- Chuck |
From: Keith M. <kei...@us...> - 2010-07-07 20:04:51
|
On Wednesday 07 July 2010 07:17:14 Charles Wilson wrote: > General comment: man, we gotta get rid of the whole TAB-vs-SPACE > thing. Ditto for CRLF-vs-LF... (I vote no tabs ever; always LF). It always catches me out -- vi's "smart" replacement of runs of spaces with tabs. When I remember, I may switch it off, but since it's on by default, and since it rarely seems to have any adverse effect beyond making patches look untidy, I've generally learnt to live with it. I agree on the CRLF vs. LF issue though. > msys-coreutils: > [...snip diff...] > > Why this change, for 1.0.13-ext? It does contain executables that > depend directly on msys-intl-8.dll (and natch, on msys-1.0.dll). > Are you relying on the transitive requirement chain > > coreutils-5.97-3-msys-1.0.13-ext > --> coreutils-%-msys-%-ext > --> msys-libintl-*-msys-*-dll-8 > --> msys-core-*-bin I assume you mean coreutils-5.97-3-msys-1.0.13-ext --> coreutils-%-msys-%-bin ^^^ --> msys-libintl-*-msys-*-dll-8 --> msys-core-*-bin in which case, yes. > ? Subject to our conversion in the other subthread of this > conversation, I don't think you should do that. I take on board your concerns about possible brittleness of any optimisation based on human presumption of a dependency declared in an *external* package, but in this case it's a completely local optimisation, so I think it's pretty safe. > msys-core: > ================================ > First, do all of these releases need to use the construction: > <release tarname="msys-core-1.0.15-1-msys-1.0.15-bin.tar.lzma" > > <download tarname=msysCORE-1.0.15-1-msys-1.0.15-bin.tar.lzma" /> > </release> No. > rather than > <release tarname="msysCORE-1.0.15-1-msys-1.0.15-bin.tar.lzma" /> This is fine. > If not, why not (what am I forgetting?) As an attribute to a "release" element, "tarname" specifies the fully qualified *canonical* name of the package archive, (where canonical implies encapsulation of the meta data as specified in the "Package Identification HOWTO"). The "download" tag is only required for (older) packages, whose archive names don't conform to that canonical naming convention. When it appears as an attribute to a "requires" element, "tarname" serves a slightly different purpose. It still represents a canonical package name, but it doesn't map directly to an archive name. It must still be parseable by pkginfo(), and the package name field, (i.e. the first field, preceding the package version), is used as a look-up key for the providing package declaration within the XML database, where it must match the "name" attribute, or any one of the names listed within an "alias" attribute, of the declaring "package" element itself. mingw-get does not require that the first field of the "tarname" in a "release" element be identical to the "name" attribute of the containing "package" element. > Second, while I assumed (and the comments in the .xml file state) > that the license file and documentation lives in the msys-core-bin > package, Cesar's latest release split those into separate -doc and > -lic packages. So, this .xml needs a lot of modification; also, > this makes the <license /> tag a little hard to manage to be > accurate for both <= 1.0.14 and >= 1.0.15. So, we'd need to embed separate "licence" tags *within* each of the respective "release" elements, (or at least within those which don't conform to the generalised packaging strategy; I'm aiming for scoping rules similar to those of C or Pascal -- start within the "release" element itself, look for the "licence" tag; if not present, look outward and choose the first hit in the innermost containing scope to provide one). > Maybe we should cut bait instead of fish, and -- at least for the > msys-core.xml file -- specify ONLY 1.0.15 and newer, and don't > include any information regarding 1.0.14 and older. Yes. I'd be inclined to strip out all references to all but the most recent releases of *all* packages, at the time of initial publication of the manifests. > Third, > > - <requires eq="msys-coreutils-*-msys-*-bin.tar" /> > + <!-- update this once the appropriate .xml files exist > <requires eq="msys-bash-*-msys-*-bin.tar" /> > - <requires eq="msys-grep-*-msys-*-bin.tar" /> > - <requires eq="msys-sed-*-msys-*-bin.tar" /> > <requires eq="msys-gawk-*-msys-*-bin.tar" /> > + ... > + --> > > I can see commenting out or removing references to the xml files > that haven't yet been validated. But why put msys-bash-bin inside > that comment block? msys-bash.xml we have, and it is (in the > process of being) validated...msys-coreutils-ext contains a script > /bin/groups, that script require bash, msys-bash.xml is ready, > ergo...require it. A relic from an an earlier phase of my testing, which I've overlooked up until now; this is in the requirements list for msys-core-ext, which I've not yet addressed in depth. > Also, that script ALSO calls an application in msys-coreutils-bin > (e.g. '/bin/groups' needs 'id.exe') so msys-coreutils-ext has a > direct dependency on msys-coreutils-bin. So, it should be listed > even in our temporarily abbreviated requires list. But shouldn't this be more correctly handled in msys-coreutils.xml? That said, however, /etc/profile also depends on msys-coreutils-bin, and we've packaged that within msys-core-bin. We don't declare that because it would result in a circular dependency, but the script is there to facilitate bash start up, so perhaps /etc/profile should really be packaged with msys-bash-bin, and the dependency should be declared there? Doing this augments the bash package with local customisations, which we maybe don't want. This can get very silly, if we try to cover all the bases, but maybe msys-bash.xml should declare a dependency of its "bin" component on msys-coreutils-bin, because without it, if I do C:\MinGW\bin> mingw-get install msys-bash-bin I can install the shell, but if I then do C:\MinGW\bin> ..\..\MSYS\1.0\bin\sh --login -i the shell will start up, but it fails to establish my home directory, and complains loudly about it, because mkdir and cp aren't available unless I also install msys-coreutils-bin. > msys-gettext: > ================================ > msys-gettext-dev does too require msys-core-bin (Pbbbbbt!), > because it has exe's that directly depend on msys-1.0.dll > itself. Ditto msys-gettext-bin. > > Otherwise, you're relying on the transitive requires thru > the various OTHER dll packages, to ensure that msys-1.0.dll > gets installed. Probably a VERY safe bet, but... I think so, but we're getting back to the do we or don't we declare dependencies when *we* know they are duplicated through DLL package references discussion; I can accept your argument for declaring them, even though we know it may not be strictly optimal to do so. > All of the others seem fine. Thanks for your diligence on this, > Keith. You're welcome. -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2010-07-07 22:03:25
|
On 7/7/2010 12:09 PM, Keith Marshall wrote: > On Wednesday 07 July 2010 07:17:14 Charles Wilson wrote: >> General comment: man, we gotta get rid of the whole TAB-vs-SPACE >> thing. Ditto for CRLF-vs-LF... (I vote no tabs ever; always LF). > > It always catches me out -- vi's "smart" replacement of runs of spaces > with tabs. When I remember, I may switch it off, but since it's on by > default, and since it rarely seems to have any adverse effect beyond > making patches look untidy, I've generally learnt to live with it. I > agree on the CRLF vs. LF issue though. Maybe we should add: <!-- vim: set nocompatible expandtab tw=80 ts=4 sw=4 ff=unix: --> to the bottom of every file? (You have to have 'set modeline' in your .vimrc, or it will have no effect). >> msys-coreutils: >> [...snip diff...] >> >> Why this change, for 1.0.13-ext? It does contain executables that >> depend directly on msys-intl-8.dll (and natch, on msys-1.0.dll). >> Are you relying on the transitive requirement chain ... > I assume you mean > > coreutils-5.97-3-msys-1.0.13-ext > --> coreutils-%-msys-%-bin > ^^^ > --> msys-libintl-*-msys-*-dll-8 > --> msys-core-*-bin > > in which case, yes. Yes, oops. >> ? Subject to our conversion in the other subthread of this >> conversation, I don't think you should do that. > > I take on board your concerns about possible brittleness of any > optimisation based on human presumption of a dependency declared in > an *external* package, but in this case it's a completely local > optimisation, so I think it's pretty safe. OK. I figured that's what you would say; and it's a reasonable compromise. >> msys-core: >> ================================ >> First, do all of these releases need to use the construction: >> <release tarname="msys-core-1.0.15-1-msys-1.0.15-bin.tar.lzma"> >> <download tarname=msysCORE-1.0.15-1-msys-1.0.15-bin.tar.lzma" /> >> </release> > > No. > >> rather than >> <release tarname="msysCORE-1.0.15-1-msys-1.0.15-bin.tar.lzma" /> > > This is fine. > >> If not, why not (what am I forgetting?) > > As an attribute to a "release" element, "tarname" specifies the fully > qualified *canonical* name of the package archive, (where canonical > implies encapsulation of the meta data as specified in the "Package > Identification HOWTO"). The "download" tag is only required for > (older) packages, whose archive names don't conform to that canonical > naming convention. > > When it appears as an attribute to a "requires" element, "tarname" > serves a slightly different purpose. It still represents a canonical > package name, but it doesn't map directly to an archive name. It > must still be parseable by pkginfo(), and the package name field, > (i.e. the first field, preceding the package version), is used as a > look-up key for the providing package declaration within the XML > database, where it must match the "name" attribute, or any one of the > names listed within an "alias" attribute, of the declaring "package" > element itself. > > mingw-get does not require that the first field of the "tarname" > in a "release" element be identical to the "name" attribute of the > containing "package" element. Ah, that was it. Thanks. (Boy, my internal cache memory is getting smaller every year...stuff gets swapped out too soon unless I'm working with it daily.) >> Second, while I assumed (and the comments in the .xml file state) >> that the license file and documentation lives in the msys-core-bin >> package, Cesar's latest release split those into separate -doc and >> -lic packages. So, this .xml needs a lot of modification; also, >> this makes the<license /> tag a little hard to manage to be >> accurate for both<= 1.0.14 and>= 1.0.15. > > So, we'd need to embed separate "licence" tags *within* each of the > respective "release" elements, (or at least within those which don't > conform to the generalised packaging strategy; I'm aiming for scoping > rules similar to those of C or Pascal -- start within the "release" > element itself, look for the "licence" tag; if not present, look > outward and choose the first hit in the innermost containing > scope to provide one). That seems reasonable. But it's not yet reflected in the current code, right? >> Maybe we should cut bait instead of fish, and -- at least for the >> msys-core.xml file -- specify ONLY 1.0.15 and newer, and don't >> include any information regarding 1.0.14 and older. > > Yes. I'd be inclined to strip out all references to all but the most > recent releases of *all* packages, at the time of initial publication > of the manifests. This is also okay with me. I've been using all the new versions exclusively since mid-April with no ill effects, and now Cesar has said the latest msysCORE was built using an environment that was populated with the new(er) packages, too. So, I think this is 'safe'. >> Third, >> >> -<requires eq="msys-coreutils-*-msys-*-bin.tar" /> >> +<!-- update this once the appropriate .xml files exist >> <requires eq="msys-bash-*-msys-*-bin.tar" /> >> -<requires eq="msys-grep-*-msys-*-bin.tar" /> >> -<requires eq="msys-sed-*-msys-*-bin.tar" /> >> <requires eq="msys-gawk-*-msys-*-bin.tar" /> >> + ... >> + --> >> >> I can see commenting out or removing references to the xml files >> that haven't yet been validated. But why put msys-bash-bin inside >> that comment block? msys-bash.xml we have, and it is (in the >> process of being) validated...msys-coreutils-ext contains a script >> /bin/groups, that script require bash, msys-bash.xml is ready, >> ergo...require it. > > A relic from an an earlier phase of my testing, which I've overlooked > up until now; this is in the requirements list for msys-core-ext, > which I've not yet addressed in depth. Ah. >> Also, that script ALSO calls an application in msys-coreutils-bin >> (e.g. '/bin/groups' needs 'id.exe') so msys-coreutils-ext has a ^^^^^^^^^^^^^^^^^^ Sorry, this should read msys-core-ext /bin/groups is in msys-core-ext, and has a dep on msys-coreUTILS-BIN. >> direct dependency on msys-coreutils-bin. So, it should be listed >> even in our temporarily abbreviated requires list. > > But shouldn't this be more correctly handled in msys-coreutils.xml? No, that's a confusion brought on by my typo above. > That said, however, /etc/profile also depends on msys-coreutils-bin, > and we've packaged that within msys-core-bin. We don't declare that > because it would result in a circular dependency, but the script is > there to facilitate bash start up, so perhaps /etc/profile should > really be packaged with msys-bash-bin, and the dependency should be > declared there? Doing this augments the bash package with local > customisations, which we maybe don't want. Exactly. Everything depends on msys-core-bin when you get down to it, so /etc/profile will always be there. I tend to view /etc/* files not as "scripts that you execute" so much, as "scripts that are executed BY" something else. In this case, bash. So, from that perspective, it makes sense that bash-bin would get the (customized) /etc/profile from msys-core-bin, and the fact that without coreutils-bin the cp and mkgroup are "missing" is immaterial at THAT level (msys-core.xml) because /etc/profile "won't" be executed, without bash. > This can get very silly, > if we try to cover all the bases, but maybe msys-bash.xml should > declare a dependency of its "bin" component on msys-coreutils-bin, > because without it, if I do > > C:\MinGW\bin> mingw-get install msys-bash-bin > > I can install the shell, but if I then do > > C:\MinGW\bin> ..\..\MSYS\1.0\bin\sh --login -i > > the shell will start up, but it fails to establish my home directory, > and complains loudly about it, because mkdir and cp aren't available > unless I also install msys-coreutils-bin. It's a little odd, but I think adding msys-coreutils-bin as a dependency of msys-bash-bin makes more sense that putting our customized MSYS version of /etc/profile into the bash package. Putting /etc/bashrc or /etc/bash_profile, or /etc/skel/.bashrc into the msys-bash-bin package -- maybe. Cygwin puts all this junk in a "basefiles" package. Many linuxes do it that way too. But I think that's overkill for msys. >> msys-gettext: >> ================================ >> msys-gettext-dev does too require msys-core-bin (Pbbbbbt!), >> because it has exe's that directly depend on msys-1.0.dll >> itself. Ditto msys-gettext-bin. >> >> Otherwise, you're relying on the transitive requires thru >> the various OTHER dll packages, to ensure that msys-1.0.dll >> gets installed. Probably a VERY safe bet, but... > > I think so, but we're getting back to the do we or don't we declare > dependencies when *we* know they are duplicated through DLL package > references discussion; I can accept your argument for declaring them, > even though we know it may not be strictly optimal to do so. Ack. >> All of the others seem fine. Thanks for your diligence on this, >> Keith. > > You're welcome. I think we've reached consensus on this subset of the xml files. Do you want to commit the appropriate changes to CVS? Then what? Do we "publish" the results as msys-alpha-1, or keep working "privately" to expand msys-base to the next round of elements? Also, didn't we at one point say that perhaps there should be two meta packages defined in msys-base.xml: a REALLY stripped down bare bones one, and then the "real" msys-base that duplicates the old monolithic installer's footprint? I think we also said that the "real" msys-base meta package should NOT depend on the "tiny" one...so something like the following <package name="msys-minimal" class="virtual"> <description lang="en" title="A Tiny MSYS Installation"> <paragraph>This meta package provides the smallest possible functional MSYS installation. It includes only MSYS itself, a bash shell, and a few absolutely required commandline utilities. Other components can be added manually as needed. </paragraph> </description> <component class="bin"> <release tarname="msys-tiny-YYYYMMDDNN-msys-bin.meta" /> <requires eq="msys-bash-*-msys-*-bin.tar" /> <requires eq="msys-coreutils-*-msys-*-bin.tar" /> </component> </package> <package name="msys-base" class="virtual"> <affiliate group="MSYS Base System" /> <description lang="en" title="A Basic MSYS Installation (meta)"> <paragraph>This meta package contains the components necessary to create a basic, small, but relatively useful MSYS installation. It includes the core system, bash, various command line utilities, and archiving/compression tools. It attempts to replicate, with certain judicious additions and deletions, the set of tools originally installed by the old MSYS monolitic installers. ^^^^^^^^^ monolithic </paragraph> </description> <component class="bin"> <release tarname="msys-base-YYYYMMDDNN-msys-bin.meta" /> <requires eq="msys-bash-*-msys-*-bin.tar" /> <requires eq="msys-coreutils-*-msys-*-bin.tar" /> ... and we add more here as the .xmls are finalized ... </component> </package> -- Chuck |
From: Keith M. <kei...@us...> - 2010-07-08 20:21:33
|
On Wednesday 07 July 2010 23:03:49 Charles Wilson wrote: > On 7/7/2010 12:09 PM, Keith Marshall wrote: > > On Wednesday 07 July 2010 07:17:14 Charles Wilson wrote: > >> General comment: man, we gotta get rid of the whole TAB-vs-SPACE > >> thing. Ditto for CRLF-vs-LF... (I vote no tabs ever; always > >> LF). > > > > It always catches me out -- vi's "smart" replacement of runs of > > spaces with tabs. When I remember, I may switch it off, but > > since it's on by default, and since it rarely seems to have any > > adverse effect beyond making patches look untidy, I've generally > > learnt to live with it. I agree on the CRLF vs. LF issue though. > > Maybe we should add: > > <!-- vim: set nocompatible expandtab tw=80 ts=4 sw=4 ff=unix: --> > > to the bottom of every file? Fine by me. Personally, I prefer a shiftwidth of 2, but that's a minor detail. > (You have to have 'set modeline' in your .vimrc, or it will have no > effect). Yeah. I have that anyway; it's a feature I use extensively :-) > >> msys-coreutils: > > I take on board your concerns about possible brittleness of any > > optimisation based on human presumption of a dependency declared > > in an *external* package, but in this case it's a completely > > local optimisation, so I think it's pretty safe. > > OK. I figured that's what you would say; and it's a reasonable > compromise. Okay. Let's progress it on that basis. > >> msys-core: > > mingw-get does not require that the first field of the "tarname" > > in a "release" element be identical to the "name" attribute of > > the containing "package" element. > > Ah, that was it. Thanks. (Boy, my internal cache memory is > getting smaller every year...stuff gets swapped out too soon unless > I'm working with it daily.) I'll need to pull all these snippets of information together, into some sort of formal spec; I've been holding off, while the details remain in a state of flux, but I guess I can't keep putting it off for much longer. > >> Second, while I assumed (and the comments in the .xml file > >> state) that the license file and documentation lives in the > >> msys-core-bin package, Cesar's latest release split those into > >> separate -doc and -lic packages. So, this .xml needs a lot of > >> modification; also, this makes the<license /> tag a little hard > >> to manage to be accurate for both<= 1.0.14 and>= 1.0.15. > > > > So, we'd need to embed separate "licence" tags *within* each of > > the respective "release" elements, (or at least within those > > which don't conform to the generalised packaging strategy; I'm > > aiming for scoping rules similar to those of C or Pascal -- start > > within the "release" element itself, look for the "licence" tag; > > if not present, look outward and choose the first hit in the > > innermost containing scope to provide one). > > That seems reasonable. But it's not yet reflected in the current > code, right? Yes. The code doesn't do *anything* with "licence" tags yet. > >> Maybe we should cut bait instead of fish, and -- at least for > >> the msys-core.xml file -- specify ONLY 1.0.15 and newer, and > >> don't include any information regarding 1.0.14 and older. > > > > Yes. I'd be inclined to strip out all references to all but the > > most recent releases of *all* packages, at the time of initial > > publication of the manifests. > > This is also okay with me. I've been using all the new versions > exclusively since mid-April with no ill effects, and now Cesar has > said the latest msysCORE was built using an environment that was > populated with the new(er) packages, too. So, I think this is > 'safe'. Good. I'll tidy up the files I've reviewed so far, on this basis, and commit them, (or would you prefer to see patches first)? > >> Also, that script ALSO calls an application in > >> msys-coreutils-bin (e.g. '/bin/groups' needs 'id.exe') so > >> msys-coreutils-ext has a > > ^^^^^^^^^^^^^^^^^^ > Sorry, this should read > msys-core-ext > > /bin/groups is in msys-core-ext, and has a dep on > msys-coreUTILS-BIN. Are you sure? I don't see it there, (in msys-core-ext), but I do see it in msys-coreutils-ext. I think you were right the first time. > >> direct dependency on msys-coreutils-bin. So, it should be > >> listed even in our temporarily abbreviated requires list. > > > > But shouldn't this be more correctly handled in > > msys-coreutils.xml? > > No, that's a confusion brought on by my typo above. I don't think so. See above. > > That said, however, /etc/profile also depends on > > msys-coreutils-bin, and we've packaged that within msys-core-bin. > > We don't declare that because it would result in a circular > > dependency, but the script is there to facilitate bash start up, > > so perhaps /etc/profile should really be packaged with > > msys-bash-bin, and the dependency should be declared there? > > Doing this augments the bash package with local customisations, > > which we maybe don't want. > > Exactly. Everything depends on msys-core-bin when you get down to > it, so /etc/profile will always be there. I tend to view /etc/* > files not as "scripts that you execute" so much, as "scripts that > are executed BY" something else. > > [...snip...] > > It's a little odd, but I think adding msys-coreutils-bin as a > dependency of msys-bash-bin makes more sense that putting our > customized MSYS version of /etc/profile into the bash package. I agree. I'll add that dependency, before committing. > Putting /etc/bashrc or /etc/bash_profile, or /etc/skel/.bashrc into > the msys-bash-bin package -- maybe. Cygwin puts all this junk in a > "basefiles" package. Many linuxes do it that way too. But I think > that's overkill for msys. Agreed. I don't think there's any great need for that. > >> msys-gettext: > >> ================================ > >> msys-gettext-dev does too require msys-core-bin (Pbbbbbt!), > >> because it has exe's that directly depend on msys-1.0.dll > >> itself. Ditto msys-gettext-bin. > >> > >> Otherwise, you're relying on the transitive requires thru > >> the various OTHER dll packages, to ensure that msys-1.0.dll > >> gets installed. Probably a VERY safe bet, but... > > > > I think so, but we're getting back to the do we or don't we > > declare dependencies when *we* know they are duplicated through > > DLL package references discussion; I can accept your argument for > > declaring them, even though we know it may not be strictly > > optimal to do so. > > Ack. Okay. So, on this basis, I'll leave msys-gettext.xml as it is in CVS. > >> All of the others seem fine. Thanks for your diligence on this, > >> Keith. > > > > You're welcome. > > I think we've reached consensus on this subset of the xml files. Do > you want to commit the appropriate changes to CVS? Yes, I'll do that. > Then what? Do we "publish" the results as msys-alpha-1, or keep > working "privately" to expand msys-base to the next round of > elements? I think we should push each to FRS, as we validate it, but perhaps delay any public announcement until everything is in place to deliver the full msys-base; I'll also attend to that. > Also, didn't we at one point say that perhaps there should be two > meta packages defined in msys-base.xml: > > a REALLY stripped down bare bones one, and then the "real" > msys-base that duplicates the old monolithic installer's footprint? I believe we did; it's certainly something I have in mind to do, and I think we are just about there with "msys-tiny". > I think we also said that the "real" msys-base meta package should > NOT depend on the "tiny" one...so something like the following > [...snip XML specification...] Looks good to me. I'll integrate than into my working copy, before I commit it to CVS, and publish. -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2010-07-08 21:36:12
|
On 7/8/2010 10:25 AM, Keith Marshall wrote: > On Wednesday 07 July 2010 23:03:49 Charles Wilson wrote: >> Maybe we should add: >> >> <!-- vim: set nocompatible expandtab tw=80 ts=4 sw=4 ff=unix: --> >> >> to the bottom of every file? > > Fine by me. Personally, I prefer a shiftwidth of 2, but that's a > minor detail. That was a typo in my testing. ts=2 sw=2 is better. >> (You have to have 'set modeline' in your .vimrc, or it will have no >> effect). > > Yeah. I have that anyway; it's a feature I use extensively :-) I used to. I don't know why it disappeared, but its unexpected absence cause some major hair-pulling last night. It's back now. >> OK. I figured that's what you would say; and it's a reasonable >> compromise. > > Okay. Let's progress it on that basis. Ack. > I'll need to pull all these snippets of information together, into > some sort of formal spec; I've been holding off, while the details > remain in a state of flux, but I guess I can't keep putting it off > for much longer. I figured it would be time for documentation after our first *complete* msys rollout. Surely 50+ .xml files is enough of a basis set to work out most of the kinks -- but only 7 or 8 is not. >> That seems reasonable. But it's not yet reflected in the current >> code, right? > > Yes. The code doesn't do *anything* with "licence" tags yet. Oh, I knew that. I meant the code doesn't yet have anything implementing these general scoping rules, regardless of whether the implemented support was used to handle <licence /> or <source />. >> This is also okay with me. I've been using all the new versions >> exclusively since mid-April with no ill effects, and now Cesar has >> said the latest msysCORE was built using an environment that was >> populated with the new(er) packages, too. So, I think this is >> 'safe'. > > Good. I'll tidy up the files I've reviewed so far, on this basis, and > commit them, (or would you prefer to see patches first)? No, go ahead. I think we're in agreement. >>>> Also, that script ALSO calls an application in >>>> msys-coreutils-bin (e.g. '/bin/groups' needs 'id.exe') so >>>> msys-coreutils-ext has a >> >> ^^^^^^^^^^^^^^^^^^ >> Sorry, this should read >> msys-core-ext >> >> /bin/groups is in msys-core-ext, and has a dep on >> msys-coreUTILS-BIN. > > Are you sure? I don't see it there, (in msys-core-ext), but I do see > it in msys-coreutils-ext. I think you were right the first time. ... > I don't think so. See above. Okay, reviewing.... package xml under discussion: msys-core.xml actual component: ext Keith contents: <component class="ext"> <!-- msys-core-ext contains tools that have dependencies on components other than msys-core-bin alone. New for 1.0.15. --> <release tarname="msysCORE-1.0.15-1-msys-1.0.15-ext.tar.lzma" /> <requires eq="msys-core-%-msys-%-bin.tar" /> <!-- update this once the appropriate .xml files exist <requires eq="msys-bash-*-msys-*-bin.tar" /> <requires eq="msys-gawk-*-msys-*-bin.tar" /> ... --> </component> Orig contents: <component class="ext"> <!-- msys-core-ext contains tools that have dependencies on components other than msys-core-bin alone. New for 1.0.15. --> <release tarname="msysCORE-1.0.15-1-msys-1.0.15-ext.tar.lzma" /> <requires eq="msys-core-%-msys-%-bin.tar" /> <requires eq="msys-coreutils-*-msys-*-bin.tar" /> <requires eq="msys-bash-*-msys-*-bin.tar" /> <requires eq="msys-grep-*-msys-*-bin.tar" /> <requires eq="msys-sed-*-msys-*-bin.tar" /> <requires eq="msys-gawk-*-msys-*-bin.tar" /> </component> I said: > I can see commenting out or removing references to the xml files that > haven't yet been validated. But why put msys-bash-bin inside that > comment block? msys-bash.xml we have, and it is (in the process of > being) validated...msys-coreutils-ext contains a script /bin/groups, and this is actually a non sequitur. We're talking about msys-core-ext and what IT should require. NOT what something in msys-coreutils-ext might require. > that script require bash, msys-bash.xml is ready, ergo...require it. > > Also, that script ALSO calls an application in msys-coreutils-bin (e.g. > '/bin/groups' needs 'id.exe') so msys-coreutils-ext has a direct > dependency on msys-coreutils-bin. So, it should be listed even in our > temporarily abbreviated requires list. Now, that non sequitur above means this statement was so much nonsense. However...here's what msys-core-ext DOES contain: bin/cls bin/clsb bin/cmd bin/ftp bin/lnkcnv bin/mount bin/msysinfo bin/start bin/umount bin/which postinstall/ postinstall/pi.bat postinstall/pi.sh msys.bat pi.sh: requires sh, cat, rm, mv cmd: requires sed lnkcnv: requires cat, sed, cut, ln, rm mount: requires msysmnt, cat, tr, awk msysinfo: requires sh, ls, uname, cut, md5sum, grep, fold (also, ld, gcc, make???? I'm guessing "not present" is ok, here) unount: requires rm, cp, cat, tr, awk which: requires ls msysCORE-1.0.15-1-msys-1.0.15-bin msysmnt coreutils-5.97-3-msys-1.0.13-bin cut, cat, ln, rm, mv, cp, ls, uname, fold, tr, md5sum sed-4.2.1-2-msys-1.0.13-bin sed gawk-3.1.7-2-msys-1.0.13-bin awk bash-3.1.17-3-msys-1.0.13-bin bash sh grep-2.5.4-2-msys-1.0.13-bin grep So...the upshot is that msys-core-ext DOES actually and explicitly require all six of these packages. However, since of these five, only msys-bash.xml msys-core.xml msys-coreutils.xml are ready, I think that this component's fragment should read: <component class="ext"> <!-- msys-core-ext contains tools that have dependencies on components other than msys-core-bin alone. --> <release tarname="msysCORE-1.0.15-1-msys-1.0.15-ext.tar.lzma" /> <requires eq="msys-core-%-msys-%-bin.tar" /> <requires eq="msys-coreutils-*-msys-*-bin.tar" /> <requires eq="msys-bash-*-msys-*-bin.tar" /> <!-- update this once the appropriate .xml files exist <requires eq="msys-grep-*-msys-*-bin.tar" /> <requires eq="msys-sed-*-msys-*-bin.tar" /> <requires eq="msys-gawk-*-msys-*-bin.tar" /> --> </component> Better? >> It's a little odd, but I think adding msys-coreutils-bin as a >> dependency of msys-bash-bin makes more sense that putting our >> customized MSYS version of /etc/profile into the bash package. > > I agree. I'll add that dependency, before committing. Ack. >> Putting /etc/bashrc or /etc/bash_profile, or /etc/skel/.bashrc into >> the msys-bash-bin package -- maybe. Cygwin puts all this junk in a >> "basefiles" package. Many linuxes do it that way too. But I think >> that's overkill for msys. > > Agreed. I don't think there's any great need for that. Ack. >>>> msys-gettext: >>>> ================================ ... > Okay. So, on this basis, I'll leave msys-gettext.xml as it is in CVS. Ack. (except for adding the modeline?) >> I think we've reached consensus on this subset of the xml files. Do >> you want to commit the appropriate changes to CVS? > > Yes, I'll do that. Thanks. >> Then what? Do we "publish" the results as msys-alpha-1, or keep >> working "privately" to expand msys-base to the next round of >> elements? > > I think we should push each to FRS, as we validate it, but perhaps > delay any public announcement until everything is in place to deliver > the full msys-base; I'll also attend to that. Sounds good. >> Also, didn't we at one point say that perhaps there should be two >> meta packages defined in msys-base.xml: >> >> a REALLY stripped down bare bones one, and then the "real" >> msys-base that duplicates the old monolithic installer's footprint? > > I believe we did; it's certainly something I have in mind to do, and I > think we are just about there with "msys-tiny". I agree. >> I think we also said that the "real" msys-base meta package should >> NOT depend on the "tiny" one...so something like the following >> [...snip XML specification...] > > Looks good to me. I'll integrate than into my working copy, before I > commit it to CVS, and publish. Thanks. -- Chuck |
From: Charles W. <cwi...@us...> - 2010-07-11 19:31:29
|
On 7/8/2010 5:36 PM, Charles Wilson wrote: > On 7/8/2010 10:25 AM, Keith Marshall wrote: >> Looks good to me. I'll integrate than into my working copy, before I >> commit it to CVS, and publish. FYI, I've committed the following: "Add vim modelines to all .xml; retabify selected files" The "selected files" were the following mingw32/mingw32-base.xml mingw32/mingw32-binutils.xml mingw32/mingw32-gdb.xml mingw32/mingw32-runtime.xml which were the only files at present that contained TABs. They don't anymore. Now, the only files that have TABs are ChangeLog Makefile.in Makefile.comm.in I made no other content changes, so cvs update should be smooth. -- Chuck |
From: Charles W. <cwi...@us...> - 2010-07-11 21:16:46
|
On 7/11/2010 3:31 PM, Charles Wilson wrote: > > "Add vim modelines to all .xml; retabify selected files" And attached is an updated version of the current (small set of msys) manifests, modified as discussed in this thread (incl. remove all older releases). I did *not* check these in, but they seem to work as expected with mingw-get. I've also attached the patch (to the .xml files as they exist in the CVS repo) that corresponds to the 'deployed' versions in the tarball. -- Chuck |
From: Charles W. <cwi...@us...> - 2010-07-18 22:04:52
|
On 7/11/2010 5:16 PM, Charles Wilson wrote: > On 7/11/2010 3:31 PM, Charles Wilson wrote: >> >> "Add vim modelines to all .xml; retabify selected files" > > And attached is an updated version of the current (small set of msys) > manifests, modified as discussed in this thread (incl. remove all older > releases). > > I did *not* check these in, but they seem to work as expected with > mingw-get. > > I've also attached the patch (to the .xml files as they exist in the CVS > repo) that corresponds to the 'deployed' versions in the tarball. Keith, if you're not going to check your updated versions in, can I go ahead with the ones I posted on 7/11 instead, so that we can move on to the next set? I know there are some issues still remaining in mingw-get (you mentioned some conflict wrt 'requires eq=' specs) but I don't see why the iterative process of refining the manifests can't proceed independently of that effort. I think the next set would include: sed grep gawk less findutils diffutils gzip expat regex All of which (except expat and regex) would also be listed directly as part of the (growing) msys-base metapackage. Expat is listed to fill in an existing "hole" in the gettext dependencies; regex (actually, libregex) is required by less. I wouldn't have included diffutils in this list yet, except that it is required by some of the scripts included in gzip-bin. Oh, and let's start a new thread to discuss the next round of msys manifests... -- Chuck |
From: Keith M. <kei...@us...> - 2010-07-19 16:30:50
|
On Sunday 18 July 2010 23:04:25 Charles Wilson wrote: > On 7/11/2010 5:16 PM, Charles Wilson wrote: > > On 7/11/2010 3:31 PM, Charles Wilson wrote: > >> "Add vim modelines to all .xml; retabify selected files" > > > > And attached is an updated version of the current (small set of > > msys) manifests, modified as discussed in this thread (incl. remove > > all older releases). > > > > I did *not* check these in, but they seem to work as expected with > > mingw-get. > > > > I've also attached the patch (to the .xml files as they exist in > > the CVS repo) that corresponds to the 'deployed' versions in the > > tarball. > > Keith, if you're not going to check your updated versions in, can I > go ahead with the ones I posted on 7/11 instead, so that we can move > on to the next set? Uhmm. I'd already made a start on integrating the ideas you'd proposed, but things have been a bit hectic chez moi, for the past couple of weeks, (and likely to remain so for another week at least); I simply haven't had as much time to progress this, as I'd have liked. Anyway, I've merged your CVS changes with mine this morning, and, after resolving a few conflicts, I've pushed enough of the resultant files to FRS, to support distribution of msys-tiny, (and I've tested the result end-to-end). I did find a couple of errors[*], after the initial FRS push, subsequently corrected; hence msys-bash and msys-coreutils are identified by issue numbers of 2010071901, rather than 2010071900. [*] After my merge, -bin package tarball names were specified as being for MSYS-1.0.11, rather than for MSYS-1.0.13, as the actual tarballs in FRS are named; that seems to have crept in from my changes, rather than from yours, but somehow, CVS didn't catch *that* conflict. Worse than that: *I* must have caught it, during local testing, then failed to propagate the correction back from the Win2K to the Linux box. I'll commit the as-built XML code to CVS, just as soon as I can find sufficient free time; it may not be until next week. > I know there are some issues still remaining in mingw-get (you > mentioned some conflict wrt 'requires eq=' specs) I don't recall the details at present; I'll need to refresh my memory, when I can get back to this. > but I don't see why > the iterative process of refining the manifests can't proceed > independently of that effort. Agreed. > 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. > expat > regex > > All of which (except expat and regex) would also be listed directly > as part of the (growing) msys-base metapackage. Agreed. > Expat is listed to > fill in an existing "hole" in the gettext dependencies; Ack. > regex (actually, libregex) is required by less. It's also required by bash, (yes, I was surprised by that too), so it's already specified, (unless we're talking about the older ABI version, but that doesn't appear to be the case for less and bash). > I wouldn't have included diffutils in this list yet, except that it > is required by some of the scripts included in gzip-bin. Ack. > Oh, and let's start a new thread to discuss the next round of msys > manifests... Agreed. -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2010-07-19 17:24:54
|
On 7/19/2010 9:33 AM, Keith Marshall wrote: > On Sunday 18 July 2010 23:04:25 Charles Wilson wrote: >> Keith, if you're not going to check your updated versions in, can I >> go ahead with the ones I posted on 7/11 instead, so that we can move >> on to the next set? > Uhmm. I'd already made a start on integrating the ideas you'd > proposed, but things have been a bit hectic chez moi, for the past > couple of weeks, (and likely to remain so for another week at least); I > simply haven't had as much time to progress this, as I'd have liked Life happens. > Anyway, I've merged your CVS changes with mine this morning, and, after > resolving a few conflicts, I've pushed enough of the resultant files to > FRS, to support distribution of msys-tiny, (and I've tested the result > end-to-end). Great! > I did find a couple of errors[*], after the initial FRS > push, subsequently corrected; hence msys-bash and msys-coreutils are > identified by issue numbers of 2010071901, rather than 2010071900. Hmm. > [*] After my merge, -bin package tarball names were specified as being > for MSYS-1.0.11, rather than for MSYS-1.0.13, as the actual tarballs in > FRS are named; that seems to have crept in from my changes, rather than > from yours, but somehow, CVS didn't catch *that* conflict. Worse than > that: *I* must have caught it, during local testing, then failed to > propagate the correction back from the Win2K to the Linux box. That's odd. I'd chalk it up to a once-off for now, but if it happens again we might need to investigate... > I'll commit the as-built XML code to CVS, just as soon as I can find > sufficient free time; it may not be until next week. OK. The main thing I notice is the changes you *didn't* make, when removing all but the latest versions from the .xml manifests. You *could* have changed this: <component class="bin"> <release tarname="bash-3.1.17-3-msys-1.0.13-bin.tar.lzma"> <requires eq="msys-libtermcap-*-msys-*-dll-0.tar" /> <requires eq="msys-libregex-*-msys-*-dll-1.tar" /> </release> <requires eq="msys-core-*-msys-*-bin.tar" /> <requires eq="msys-coreutils-*-msys-*-bin.tar" /> </component> to this: <component class="bin"> <release tarname="bash-3.1.17-3-msys-1.0.13-bin.tar.lzma"/> <requires eq="msys-libtermcap-*-msys-*-dll-0.tar" /> <requires eq="msys-libregex-*-msys-*-dll-1.tar" /> <requires eq="msys-core-*-msys-*-bin.tar" /> <requires eq="msys-coreutils-*-msys-*-bin.tar" /> </component> But you chose not to. It looks like you are asserting a "new" (well, *everything* is new) convention, that any dependencies on DLL packages with version numbers should be listed per-release, rather than per-component. The exceptions to this convention are: msys-core-*-bin -- is listed per-component DLL components *themselves* list their dependencies on other DLLs per-component. This convention makes sense, and even the exceptions are reasonable for now (especially the first; if something depends on the MSYS dll today, it is probably never going to NOT depend on it, at least not while retaining its msys-foo-*.xml manifest name). However, we'd have to list sub-dll-deps per-release, if the scenario I outlined earlier ever came to pass -- that is, libfoo-dll-0 depends on libbar-dll-0, but then a later release of libfoo-dll-0 is compiled, which depends instead on libbar-dll-1 but libfoo's OWN interface doesn't change (and thus, retains the "-0" discriminator). Was it your intention to promulgate this convention? >> I know there are some issues still remaining in mingw-get (you >> mentioned some conflict wrt 'requires eq=' specs) > I don't recall the details at present; I'll need to refresh my memory, > when I can get back to this. It's back in this thread, somewhere... >> 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 >> >> All of which (except expat and regex) would also be listed directly >> as part of the (growing) msys-base metapackage. > Agreed. > >> Expat is listed to >> fill in an existing "hole" in the gettext dependencies; > Ack. > >> regex (actually, libregex) is required by less. > It's also required by bash, (yes, I was surprised by that too), so it's > already specified, (unless we're talking about the older ABI version, > but that doesn't appear to be the case for less and bash). > Aw, shucks. I knew that. I just forgot. IIRC, I discovered that bash, when relying on msys's internal regex impl, doesn't actually work correctly. It's probably a bug in msys's internal regex impl; cygwin's has been updated several times since we forked. More on msys-base-phase-2 in a different thread. >> I wouldn't have included diffutils in this list yet, except that it >> is required by some of the scripts included in gzip-bin. > Ack. > >> Oh, and let's start a new thread to discuss the next round of msys >> manifests... > Agreed. > -- Chuck |