On Wednesday 04 August 2010 23:19:56 Charles Wilson wrote:
> On 8/4/2010 11:24 AM, Keith Marshall wrote:
> > Okay. I've now had a look at this; reviewed and tested locally:
> > msys-diffutils.xml
> > msys-less.xml
> > msys-tar.xml
> > I notice that, within the last of these, you didn't specify
> > dependencies on msys-bzip2-bin, msys-gzip-bin or msys-xz-bin, yet
> > all are required to achieve full functionality of tar, when
> > processing compressed archives.
> Well, for tar I don't mind either way. If you think the compressor
> -bin packages should be listed, that's fine. There is, however, a
> larger issue: there are varying degrees of "required":
Sure, there are mandatory requirements, without which the application
cannot run at all, and optional requirements, without which it may run,
but with reduced functionality.
> I think that's a judgment call for the maintainer of the foo.exe
> package. (And, as with all such judgment calls, they're subject to
> debate and reconsideration on this list).
Absolutely, but in considering them, we should attempt to put ourselves
in Joe User's shoes; is he likely to think that:
$ tar tf tar-1.23-1-msys-1.0.13-bin.tar.lzma
tar (child): lzma: Cannot exec: No such file or directory
tar (child): Error is not recoverable: exiting now
tar: Child returned status 2
tar: Error is not recoverable: exiting now
is an acceptable reduction if functionality, if he doesn't put in the
leg work to resolve the hidden dependency, or will he just deem it to
be "broken"? In this case I suspect it will be the latter, so having
mingw-get resolve the dependency up-front seems preferable.
> I don't think we want to set a hard and fast rule that "anything that
> could conceivably be considered a requirement SHALL be listed in the
> xml manifest as a <requires /> element."
No; as you say, it may be a judgement call, with each case considered on
its own merits.
> > BTW, to help me keep track of what is published, I've moved the
> > corresponding package containers, in FRS, into the MSYS/BaseSystem
> > hierarchy.
> I *really* don't like this.
I was sort of expecting you to say that...
> I was hoping we would move AWAY from
> categorizing independent modules by which meta package pulled them
> in, since there will be several modules that are pulled in by
> multiple meta packages. Who "wins"?
But that isn't my primary objective...
> Besides, libiconv and gettext are NOT part of the actual msys-base
> installation, IIRC. Their manifests have been completed "so soon"
> only because they provide the libiconv-dll and libintl-dll
> components, which -- while ALSO not explicitly part of msys-base per
> se -- are pulled in as requirements of packages which ARE.
> So...should libiconv and gettext be in "BaseSystem" -- or in "MSYS
> Developer" since those are the only folks that would need the msys
> import libs for msys-libiconv-2.dll etc?
> It's this whole area of confusion that made me happy to abandon the
> old (FRS-circa-2006-driven) categorization.
Granted, there are overlaps...
> Granted, there is less of an issue now since all the files can be
> accessed via the flat 'download' namespace, but really -- if you need
> to keep track of which manifests have been updated and which have
> not, write it down somewhere, or create a wiki page.
> Or just look at what's still commented out in msys-package-list.xml.
Sure, I could do either of these for my own benefit, (and a wiki page
could even make that more public), but I'm also trying to address Joe
User's concerns, AT POINT OF DELIVERY. He looks at the [too long] list
of packages on the download page, and is scared off, (or at least he is
STILL complaining that this is intimidating, even after we segregated
MinGW and MSYS packages into separate lists). By segregating it
further, I'm really trying to present a less intimidating list for
those who just want a basic MSYS installation, but don't [yet] want to
try out mingw-get. Yes, that means I have to list some packages in
"BaseSystem" just because they provide DLLs needed for that, even though
their principal content is more appropriate to a more advanced toolkit
for specific development usage.
Maybe we need to split what I've currently assigned to MSYS/BaseSystem
into two separate hierarchies:
but I can't think of a nice name for the latter category.
> > I'm also considering prefixing "msys-" to each name there,
> > to match the XML file name, as each is addressed within
> > msys-base.xml.
> And...we just got finished REMOVING the "MSYS ..." prefix from all of
> those packages! You can't complain to the sf.net guys for monkeying
> around with the FRS directory structure one day, and then next day
> churn that same directory structure back and forth yourself.
All I'm suggesting is a rename of [virtual] package containers, with the
objective of making it easier for Joe User to find the stuff he needs;
if it doesn't fulfil that objective, then there is no point in doing
it. Any temporary benefit it might offer to me is secondary.
> "msys-foo" is better than "MSYS foo" tho, I'll grant you that.
> > With that strategy, we could then move all components which belong
> > to msys-base into that hierarchy immediately, and use the
> > application of the "msys-" prefix to indicate availability via
> > mingw-get; any objection to me progressing with this strategy?
> Are you talking about embedding this knowledge within mingw-get's
> source code,
No, definitely not!
> or simply as a social engineering indicator for us
> humans, that "msys-less" is ready, but "findutils" is not?
Primarily as an indicator to Joe User: if it's prefixed by "msys-", then
mingw-get will already deliver it, and he may wish to consider this as
his preferred method for installation; if it lacks that prefix, then he
will still need to download and install it manually. Of course, for
that to work, I'd need to state the philosophy clearly, on the wiki.
> If the former, then I do object. If the latter, well -- ok, but can
> we please stop renaming stuff soon?
The sooner, the better, yes, but we do need to devise a hierarchy which
best satisfies the preferences of the end users, (and I'm hearing their
message that they don't like the current long lists, all too clearly),
while still being maintainable for us.
> > Of your original list, the above leave only findutils and expat to
> > be addressed, so I guess these two should be tackled next. Then
> > what? msys-file and msys-make certainly belong in msys-base; maybe
> > also msys-texinfo (for install-info).
> Yes, here's the "old" MSYS-1.0.11 src directory:
> MSYS-1.0.11/ gzip-1.2.4a-MSYS-1.0.11-1/
> bash-3.1-MSYS-1.0.11-1/ less-358-MSYS-1.0.11-1/
> bzip2-1.0.3-MSYS-1.0.11-1/ lzma-4.43-MSYS-1.0.11-2/
> coreutils-5.97-MSYS-1.0.11-1/ m4-1.4.7-MSYS-1.0.11-1/
> cpmake-3.81-MSYS-1.0.11-1/ patch-2.5.4-MSYS-1.0.11-1/
> diffutils-2.8.7-MSYS-1.0.11-1/ rxvt-2.7.2-MSYS-1.0.11-1/
> file-4.16-MSYS-1.0.11-1/ sed-3.02-MSYS-1.0.11-1/
> findutils-4.3.0-MSYS-1.0.11-3/ tar-1.19.90-MSYS-1.0.11-2/
> gawk-3.1.5-MSYS-1.0.11-1/ texinfo-4.11-MSYS-1.0.11-1/
> So texinfo should definitely be in there (although we have agreed
> that rxvt should NOT).
Well, I personally consider texinfo to be more of a development tool
that as an intrinsic BaseSystem component; it's only that it provides
install-info, (with no easy mechanism for building it as a standalone
component), that really pulls it under the umbrella of satisfying the
original MSYS mission statement, (so that "make install-info" will work
for makefiles which provide it), and of course "info" itself, which
becomes a useful user space tool, once the "info" files are installed.
Of the rest, cpmake has now become the standard make, which I've already
slated for inclusion, m4 was previously included in the MSYS-DTK, and I
see little cause to promote it to msys-base now, while patch I would
also tend to consider as a developer tool, although I don't rule it out
for possible inclusion, and, as you note, we've already agreed to drop
rxvt, while continuing to offer it only as a free standing extra, which
we no longer wish to promote.
> > Anything else I've missed?
> Here's the msys-base list I originally posted. I don't think there
> was too much argument about its contents, given the old contents
> above. The only controversial element is msys-cygutils-dos2unix, but
> that's just replacing the eponymous scripts that were added then
> removed circa 1.0.12:
> <requires ge="msys-core-*-msys-*-bin.tar" />
> <requires ge="msys-bash-*-msys-*-bin.tar" />
> <requires ge="msys-bzip2-*-msys-*-bin.tar" />
> <requires ge="msys-coreutils-*-msys-*-bin.tar" />
> <requires ge="msys-cygutils-dos2unix-*-msys-*-bin.tar" />
> <requires ge="msys-diffutils-*-msys-*-bin.tar" />
> <requires ge="msys-file-*-msys-*-bin.tar" />
> <requires ge="msys-findutils-*-msys-*-bin.tar" />
> <requires ge="msys-gawk-*-msys-*-bin.tar" />
> <requires ge="msys-grep-*-msys-*-bin.tar" />
> <requires ge="msys-gzip-*-msys-*-bin.tar" />
> <requires ge="msys-less-*-msys-*-bin.tar" />
> <requires ge="msys-m4-*-msys-*-bin.tar" />
> <requires ge="msys-make-*-msys-*-bin.tar" />
> <requires ge="msys-patch-*-msys-*-bin.tar" />
> <requires ge="msys-sed-*-msys-*-bin.tar" />
> <requires ge="msys-tar-*-msys-*-bin.tar" />
> <requires ge="msys-termcap-*-msys-*-bin.tar" />
> <requires ge="msys-texinfo-*-msys-*-bin.tar" />
> <requires ge="msys-xz-*-msys-*-bin.tar" />
> So, still missing for a "complete" msys-base would be:
Which adds only cygutils-dos2unix to those identified above. You know
my own reservations about dos2unix (and unix2dos), where a simple pair
of shell aliases or one line scripts suffices, IMO, but for the sake of
the added features these cygutils .exe variants offer, I can accept
your argument for including this.
> plus whatever dependencies are still outstanding (which are, I think,
> just expat and popt).
Okay; expat to satisfy the dangling dependency in the developer-centric
components of gettext, and popt because cygutils-dos2unix needs it.
> In case I haven't mentioned it recently, thanks for your hard work on
> getting these manifests finalized.