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).
>> [...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-%-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.
OK. I figured that's what you would say; and it's a reasonable compromise.
>> 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" />
>> 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,
>> 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'.
>> -<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
Sorry, this should read
/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"
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
> 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-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,
> 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.
<release tarname="msys-tiny-YYYYMMDDNN-msys-bin.meta" />
<requires eq="msys-bash-*-msys-*-bin.tar" />
<requires eq="msys-coreutils-*-msys-*-bin.tar" />
<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.
<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 ...