From: Earnie <ea...@us...> - 2011-10-31 12:18:07
|
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 |
From: Charles W. <cwi...@us...> - 2011-10-31 17:09:59
|
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 |
From: Keith M. <kei...@us...> - 2011-11-01 20:03:16
|
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. |
From: Earnie <ea...@us...> - 2011-11-01 20:20:46
|
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 |