On 5/12/2010 9:29 AM, Keith Marshall wrote:
> On Thursday 06 May 2010 08:19:59 Charles Wilson wrote:
>> This could lead to a given package needing to specify more than
>> one affiliate group -- which may or may not be allowed.
> You are referring to the <affiliate> tag here, right?
> mingw-get snapshots don't actually use it, but my original WX GUI
> prototype did; it is likely that it will again be used, for that
> original purpose, when we get to a working GUI implementation.
> Reading between the lines, it seems that you expect it to be related
> to dependency resolution; it isn't.
No, I thought it was kinda like a distributed version of a meta-package.
msys-dtk meta package includes (among other things)
So, msys-dtk.xml has
<requires eq="msys-cvs-*-...." />
<requires eq="msys-guile-*-...." />
BUT also, msys-cvs.xml specifies
<affiliate group="MSYS Developer Toolkit" />
and msys-guile.xml also specifies
<affiliate group="MSYS Developer Toolkit" />
as a kind of "informative note".
Furthermore, consider msys-libtool. Now, msys-libtool is actually part
of the MSYS System Builder, NOT the MSYS Developer Toolkit. However,
msys-libltdl is part of BOTH MSYS System Builder, as well as the MSYS
Developer Toolkit (by virtue of msys-ltdl-7.dll being used, in
particular, by guile). OTOH, msys-libltdl-DEV is not needed by MSYS
Developer Toolkit, so...it's a little odd:
msys-libtool-lic X X
msys-libltdl-dll X X
But you can't apply affiliate groups with granularity down to the
component level, only the package level. So, msys-libtool and
msys-libltdl are both affiliated (completely) with MSYS-SYS-BLDR, and
are both (partially) affiliated with MSYS-DTK.
But...obviously my understanding is deficient.
> The <affiliate> tags then represent sort of
> symbolic links, (or more accurately, *reverse* symbolic links), from
> the group "directories" in the hierarchy, to the package "directory".
> Just as in the real POSIX file system, there can be any arbitrary
> number of symbolic links to any entity, mingw-get will support any
> number of affiliate links to any individual package specification.
Err...huh? Maybe I'm just short on sleep, but can you give an example
of how this affiliate thing is supposed to be used? How does it differ
>> MSYS Base System (msys-base)
>> rxvt (should we remove this from the msys-base meta package?)
> IMO, yes.
consider it gone.
>> (should we add xz here?)
> I think that makes sense, but I'll leave the final decision to you
> and Cesar, between you.
I think it ought to be included, since we already include the other
compressors gzip and bzip2.
> We might even consider breaking out an "msys-tiny" -- just enough to
> deliver a working shell, (perhaps also including "mount" support --
> but that may be a step too far; again, I'll leave the final decision
> to you and Cesar.
Sure, but I think msys-base.xml should be standalone (that is, it should
explicitly <require> the packages it needs, and not "piggyback" by
>> MSYS Developer Toolkit (msys-dtk)
>> --- supplementary: not part of the ORIGINAL msysDTK from 2003, but
>> implicitly added during the 2007-Sep rebuild: the rebuilt
>> versions of some of the above required the tools below. ---
> So, reasonable to include them...
>> (should we add coreutils-ext here?)
> Again, that makes sense to me, but I'm going to pass the buck on the
> final decision.
OK, for bison, flex, lndir, vim, mktemp, and coreutils-ext.
But, given your comment on <requires> below, N-OK for crypt, gmp,
minires, and regex.
> I would very strongly recommend that we *don't* explicitly list, in
> *any* meta-package, any reference which would be implicitly included
> by <requires />; IOW, *do* leave <requires /> to get on with its job,
> without pre-empting it.
Makes sense to me.
>> MSYS System Builder (msys-dvlpr)
> All looks sane, to me.
>> No associated meta package
> I do have some questions concerning dash and rebase -- primarily
> rebase -- which I'll defer to a separate thread, but otherwise, I've
> no problem with these remaining free standing, (or integrating into
> other meta-packages, where you've indicated it may be appropriate).
Well, I consider them an emergency toolkit for "oops, my MSYS
installation is having problems; I need to do some surgery". But...if
you're lucky, you don't need them.
so, perhaps it's best if they, too, remain free-standing, so that only
those folks who actually need them download and install.
>> console2 (***)
> This one, I do have reservations about. We certainly aren't going to
> redistribute the console2 product itself -- I have serious concerns
> about the legitimacy of its GPL licensing, given that it includes
> Microsoft proprietary DLL components. I will not even contemplate
> distributing that, unless we can realise a MinGW or MSYS-GCC port,
> unfettered by such proprietary dependencies.
> However, I realise that this isn't what you're suggesting here ...
> more below.
>> (**) candidates for inclusion in expanted msys-base or msys-dtk?
> Once again, I'll go along with whatever you and Cesar decide.
See above; I'm leaning toward "no" on dash/rebase, but "yes" on xz.
>> (***) ditto, but doing this would pull in wget, unzip, and
> I take it that you *are* referring to your download-and-install
> script package, to deploy from the upstream distribution. I can go
> along with providing that, but surely it would be best kept free
> standing, (or with its own separate meta-package if desired)?
Separate is fine. And there's no need for a meta-package; its own
<requires> should pull in everything it needs.