Re: [MinGW-dvlpr] Formalize the categories

[Charles Wilson <cwilso11@us...>]

On 10/31/2011 8:17 AM, Earnie wrote:
> Keith Marshall wrote:
>> [1] I guess we need a further discussion, to formalise the categories
>> for group affiliation.  As a starting point, I propose [2]:
>>
>>   MinGW
>>     MinGW Base System
>>     MinGW Development Tools
>>     MinGW Contributed
>>       MinGW Contributed Libraries
>>       MinGW Contributed Utilities
>>   MSYS
>>     MSYS Base System
>>     MSYS Development Tools
>>     MSYS Contributed
>>       MSYS Contributed Libraries
>>       MSYS Contributed Utilities
> 
> Do we need to segregate the "Contributed Libraries" and "Contributed
> Utilities"?  Often we'll have both in one package, consider gettext for
> instance which has both utilities and a library API for public use.  I
> would prefer not to have the extra layer to think about.
> 
>   MinGW
>     MinGW Base System
>     MinGW Development Tools
>     MinGW Contributed
>   MSYS
>     MSYS Base System
>     MSYS Development Tools
>     MSYS Contributed

I (almost) agree with Earnie, that there's no need for a distinction
between "libs" and "utilities" -- e.g. where would xz go, since liblzma
is just as "important" as xz.exe?

Now, I'm not sure why both Keith and Earnie have presented their
proposals in tree form.  AFAIK, there is no actual "hierarchy" in group
affiliations -- unless, PART of both proposals is to also reorganize our
frs storage along the lines of group affiliation?

However, our current frs structure is this:

   MinGW
     MinGW Base System       (contains gcc, binutils, etc)
     (everything else goes right here)
   MSYS
     MSYS Base System        (stuff that was originally in monolithic)
     (everything else goes right here)

(with a few additional exceptions, discussed below).

IF GroupAff==FRSOrg, it seems Earnie is proposing to relocate --
everything? some things? a few things? -- from "just underneath the
subsystem directory" to a new subdirectory called "$M Development Tools"

Well...why?  I don't think THAT's necessary at all.

=-=-=-=-=-=-=-=

Going back to the "pure" Group Affiliation discussion, we currently have

     MinGW Base System       -- old mingw monolithic installer
     MinGW Development Tools -- old "msysdtk" which we now call mingwdtk
     MSYS Base System        -- old msys monolithic installer
     MSYS Development Tools  -- old "system builder" stuff

There are also a number of additional "groups" -- like "MinGW Autotools"
to make it easier to get just the autotools and its deps when you don't
want the whole mingw-dtk ball of wax.

But there are a lot of packages that don't have any group affiliation at
all.  I think that's fine -- the GUI can just create an artificial
affiliate group "MinGW Miscellaneous" and "MSYS Miscellaneous" to
present those packages.  cygwin's setup does something similar.

So, to sum up: I agree with Earnie with regards to the Affiliate Groups:

   MinGW
     MinGW Base System
     MinGW Development Tools
     MinGW Contributed
   MSYS
     MSYS Base System
     MSYS Development Tools
     MSYS Contributed

With the understanding that the GUI may create "virtual" Miscellaneous
groups for each subsystem to present unaffiliated packages.  However, I
see no reason to mirror affiliate groups within the FRS hierarchy [*] --
especially as some packages may actually belong to more than one AG, IIRC.

[*] I'd also argue for a little flattening in the FRS structure.  The
BaseSystem under mingw makes some sense, given the additional dir
structure inside it -- and the core importance to the mingw.org project
of those packages which are part of "MinGW" proper -- but the
MSYS/BaseSystem is really rather pointless *in the FRS*.

MSYS/Supplementary Tools serves simply to hide old, obsolete stuff, as
does MSYS/System Builder. Unlike (old) PDCurses, I wouldn't remove these
packages -- they are useful for historical purposes -- but I would move
them outside of our "Main" areas (MinGW/ + MSYS/).  Maybe even a new
top-level area called "Obsolete/" or "Historical" ("Archeology"? Nah,
too cute.)

Finally, MinGW/Utilities/...

   basic bsdtar -- standalone utility meant for manual unzipping, but
                   does have a mingw-get manifest.

   mingw-utils -- contains the following; current version has a
                  mingw-get manifest.  Older versions, which do exist
                  under this dir, do not have manifests.
      redir     A utility for redirecting stderr within CMD boxes
      reimp     Converts certain MS-format import libs to GNU format
      res2coff  Converts .res resource files to .o object format
      a2dll     Create a DLL from a static archive
      dsw2mak   Create gcc-compatible GNU Makefiles from Visual Studio
                6.0 workspaces
      msys-here Launch an msys window from a Windows Explorer

   wget        -- actually just stores the source code for the .exe
                  buried in mingwPORT/wget!  It's required by the GPL,
                  but both are now obsolete.  Either delete both, or
                  move both (together) to new Obsolete/ tree?

   TclTk -- I doubt this even works it is so old.  I plan to publish
            (with help from LRN and others) an updated version of this,
            which will be msys-based. [**] Existing version should be
            deleted or moved to Obsolete, when new version completed
            (or before?)

[**] The MSYS version will be complete, including sh-bang scripts and
everything normally installed.  We'll also need a (pure) MinGW version
to support building mingw-insight, but that one won't have any sh-bang
scripts (what would be the point?) other than tcl-config and the like.
I'm still working out how to support both /bin/wish.exe|/bin/tclsh.exe
and /mingw/bin/wish.exe|/mingw/bin/tclsh.exe, while allowing msys-gitk,
msys-insight, and mingw-insight to use the "correct one" regardless of
whether $MSYSTEM is MSYS or MINGW (e.g. regardless of whether $PATH has
/bin or /mingw/bin first).


Soooo...I'm not sure how to deal with the existing
   MinGW/Utilities/basic bsdtar
   MinGW/Utilities/mingw-utils
in this "flattening" proposal, but the existing wget and TclTk are obvious.

--
Chuck

[MinGW-dvlpr] Formalize the categories

[Earnie <earnie@us...>]

Keith Marshall wrote:
> [1] I guess we need a further discussion, to formalise the categories
> for group affiliation.  As a starting point, I propose [2]:
>
>   MinGW
>     MinGW Base System
>     MinGW Development Tools
>     MinGW Contributed
>       MinGW Contributed Libraries
>       MinGW Contributed Utilities
>   MSYS
>     MSYS Base System
>     MSYS Development Tools
>     MSYS Contributed
>       MSYS Contributed Libraries
>       MSYS Contributed Utilities

Do we need to segregate the "Contributed Libraries" and "Contributed
Utilities"?  Often we'll have both in one package, consider gettext for
instance which has both utilities and a library API for public use.  I
would prefer not to have the extra layer to think about.

  MinGW
    MinGW Base System
    MinGW Development Tools
    MinGW Contributed
  MSYS
    MSYS Base System
    MSYS Development Tools
    MSYS Contributed

Earnie

Re: [MinGW-dvlpr] Formalize the categories

[Charles Wilson <cwilso11@us...>]

On 10/31/2011 8:17 AM, Earnie wrote:
> Keith Marshall wrote:
>> [1] I guess we need a further discussion, to formalise the categories
>> for group affiliation.  As a starting point, I propose [2]:
>>
>>   MinGW
>>     MinGW Base System
>>     MinGW Development Tools
>>     MinGW Contributed
>>       MinGW Contributed Libraries
>>       MinGW Contributed Utilities
>>   MSYS
>>     MSYS Base System
>>     MSYS Development Tools
>>     MSYS Contributed
>>       MSYS Contributed Libraries
>>       MSYS Contributed Utilities
> 
> Do we need to segregate the "Contributed Libraries" and "Contributed
> Utilities"?  Often we'll have both in one package, consider gettext for
> instance which has both utilities and a library API for public use.  I
> would prefer not to have the extra layer to think about.
> 
>   MinGW
>     MinGW Base System
>     MinGW Development Tools
>     MinGW Contributed
>   MSYS
>     MSYS Base System
>     MSYS Development Tools
>     MSYS Contributed

I (almost) agree with Earnie, that there's no need for a distinction
between "libs" and "utilities" -- e.g. where would xz go, since liblzma
is just as "important" as xz.exe?

Now, I'm not sure why both Keith and Earnie have presented their
proposals in tree form.  AFAIK, there is no actual "hierarchy" in group
affiliations -- unless, PART of both proposals is to also reorganize our
frs storage along the lines of group affiliation?

However, our current frs structure is this:

   MinGW
     MinGW Base System       (contains gcc, binutils, etc)
     (everything else goes right here)
   MSYS
     MSYS Base System        (stuff that was originally in monolithic)
     (everything else goes right here)

(with a few additional exceptions, discussed below).

IF GroupAff==FRSOrg, it seems Earnie is proposing to relocate --
everything? some things? a few things? -- from "just underneath the
subsystem directory" to a new subdirectory called "$M Development Tools"

Well...why?  I don't think THAT's necessary at all.

=-=-=-=-=-=-=-=

Going back to the "pure" Group Affiliation discussion, we currently have

     MinGW Base System       -- old mingw monolithic installer
     MinGW Development Tools -- old "msysdtk" which we now call mingwdtk
     MSYS Base System        -- old msys monolithic installer
     MSYS Development Tools  -- old "system builder" stuff

There are also a number of additional "groups" -- like "MinGW Autotools"
to make it easier to get just the autotools and its deps when you don't
want the whole mingw-dtk ball of wax.

But there are a lot of packages that don't have any group affiliation at
all.  I think that's fine -- the GUI can just create an artificial
affiliate group "MinGW Miscellaneous" and "MSYS Miscellaneous" to
present those packages.  cygwin's setup does something similar.

So, to sum up: I agree with Earnie with regards to the Affiliate Groups:

   MinGW
     MinGW Base System
     MinGW Development Tools
     MinGW Contributed
   MSYS
     MSYS Base System
     MSYS Development Tools
     MSYS Contributed

With the understanding that the GUI may create "virtual" Miscellaneous
groups for each subsystem to present unaffiliated packages.  However, I
see no reason to mirror affiliate groups within the FRS hierarchy [*] --
especially as some packages may actually belong to more than one AG, IIRC.

[*] I'd also argue for a little flattening in the FRS structure.  The
BaseSystem under mingw makes some sense, given the additional dir
structure inside it -- and the core importance to the mingw.org project
of those packages which are part of "MinGW" proper -- but the
MSYS/BaseSystem is really rather pointless *in the FRS*.

MSYS/Supplementary Tools serves simply to hide old, obsolete stuff, as
does MSYS/System Builder. Unlike (old) PDCurses, I wouldn't remove these
packages -- they are useful for historical purposes -- but I would move
them outside of our "Main" areas (MinGW/ + MSYS/).  Maybe even a new
top-level area called "Obsolete/" or "Historical" ("Archeology"? Nah,
too cute.)

Finally, MinGW/Utilities/...

   basic bsdtar -- standalone utility meant for manual unzipping, but
                   does have a mingw-get manifest.

   mingw-utils -- contains the following; current version has a
                  mingw-get manifest.  Older versions, which do exist
                  under this dir, do not have manifests.
      redir     A utility for redirecting stderr within CMD boxes
      reimp     Converts certain MS-format import libs to GNU format
      res2coff  Converts .res resource files to .o object format
      a2dll     Create a DLL from a static archive
      dsw2mak   Create gcc-compatible GNU Makefiles from Visual Studio
                6.0 workspaces
      msys-here Launch an msys window from a Windows Explorer

   wget        -- actually just stores the source code for the .exe
                  buried in mingwPORT/wget!  It's required by the GPL,
                  but both are now obsolete.  Either delete both, or
                  move both (together) to new Obsolete/ tree?

   TclTk -- I doubt this even works it is so old.  I plan to publish
            (with help from LRN and others) an updated version of this,
            which will be msys-based. [**] Existing version should be
            deleted or moved to Obsolete, when new version completed
            (or before?)

[**] The MSYS version will be complete, including sh-bang scripts and
everything normally installed.  We'll also need a (pure) MinGW version
to support building mingw-insight, but that one won't have any sh-bang
scripts (what would be the point?) other than tcl-config and the like.
I'm still working out how to support both /bin/wish.exe|/bin/tclsh.exe
and /mingw/bin/wish.exe|/mingw/bin/tclsh.exe, while allowing msys-gitk,
msys-insight, and mingw-insight to use the "correct one" regardless of
whether $MSYSTEM is MSYS or MINGW (e.g. regardless of whether $PATH has
/bin or /mingw/bin first).


Soooo...I'm not sure how to deal with the existing
   MinGW/Utilities/basic bsdtar
   MinGW/Utilities/mingw-utils
in this "flattening" proposal, but the existing wget and TclTk are obvious.

--
Chuck

Re: [MinGW-dvlpr] Formalize the categories

[Keith Marshall <keithmarshall@us...>]

On 31/10/11 17:09, Charles Wilson wrote:
> On 10/31/2011 8:17 AM, Earnie wrote:
>> Keith Marshall wrote:
>>> [1] I guess we need a further discussion, to formalise the categories
>>> for group affiliation.  As a starting point, I propose [2]:
>>>
>>>   MinGW
>>>     MinGW Base System
>>>     MinGW Development Tools
>>>     MinGW Contributed
>>>       MinGW Contributed Libraries
>>>       MinGW Contributed Utilities
>>>   MSYS
>>>     MSYS Base System
>>>     MSYS Development Tools
>>>     MSYS Contributed
>>>       MSYS Contributed Libraries
>>>       MSYS Contributed Utilities
>> 
>> Do we need to segregate the "Contributed Libraries" and "Contributed
>> Utilities"?  Often we'll have both in one package, consider gettext for
>> instance which has both utilities and a library API for public use.  I
>> would prefer not to have the extra layer to think about.

What's to think about?  As a user I might be searching for libraries,
but not utilities, or vice-versa; I don't want my view of available
packages to be cluttered/diluted by packages in a category I'm not
interested in right now.  As a package maintainer, if both selection
criteria are satisfied, I register affiliations with both.  Why do you
want to deny users a potentially useful search capability, just because
your package might fulfil a pair of independent (but not necessarily
mutually exclusive) criteria?

>>   MinGW
>>     MinGW Base System
>>     MinGW Development Tools
>>     MinGW Contributed
>>   MSYS
>>     MSYS Base System
>>     MSYS Development Tools
>>     MSYS Contributed
> 
> I (almost) agree with Earnie, that there's no need for a distinction
> between "libs" and "utilities" -- e.g. where would xz go, since liblzma
> is just as "important" as xz.exe?

It has NOTHING whatsoever to do with where ANYTHING might GO.  xz and
liblzma go (in the FRS) wherever the maintainer chooses to upload them;
this has no bearing on mingw-get affiliate (concept) association.

> Now, I'm not sure why both Keith and Earnie have presented their
> proposals in tree form.  AFAIK, there is no actual "hierarchy" in group
> affiliations -- unless, PART of both proposals is to also reorganize our
> frs storage along the lines of group affiliation?
> 
> However, our current frs structure is this: ...

The FRS structure is 100% irrelevant, in the context of my intent for
this discussion.  Earnie, you have pre-empted the new thread starter
message which I promised, seemingly jumping the gun to take off in (what
is apparently) entirely the wrong direction.

Chuck, mingw-get affiliations ARE hierarchical BY DEFINITION; the
hierarchy is established by the package-group-hierarchy elements, as
defined in the XML catalogues.  However, this is completely unrelated to
the physical structure of the FRS; rather, it is a mechanism for users
to refine their search criteria for the global mingw-get package list,
and so reduce the content of the list view to a subset which is most
likely to deliver a particular capability of interest.

-- 
Regards,
Keith.

Re: [MinGW-dvlpr] Formalize the categories

[Earnie <earnie@us...>]

Keith Marshall wrote:
> 
> The FRS structure is 100% irrelevant, in the context of my intent for
> this discussion.  Earnie, you have pre-empted the new thread starter
> message which I promised, seemingly jumping the gun to take off in (what
> is apparently) entirely the wrong direction.
> 

I obviously missed that point.

However, it is still a discussion needing discussed and the impetus of
the mail you responded to which is what caused my confusion.

Earnie