From: Cesar S. <ces...@gm...> - 2009-03-13 03:32:08
|
Dear MinGW developers, It seems to me that MSYS 1.0.11 is currently quite stable, and is otherwise good enough for general use. I think now is a good time as any for cutting a stable release. I just need to finish touching up the release notes, and I will be able to issue a release candidate. On the other hand, by releasing now, I am temporarily backing up on the idea of an unified MinGW/MSYS/DTK/ports net-installer/updater. Instead, I'll use the currently available Inno-based installer of MSYS-1.0.10. In fact, all the work to update it to 1.0.11 seems to be in CVS already. This being over, I do intend to work on the installer. I think I'll begin to put together a gui-independent library to deal with unpacking tarballs, checking for updates, making downloads, following dependencies, reading config files, etc. As for the near future, some MSYS tools still have very old versions that could be updated in the short term (e.g., sed and grep). They could be dealt with by doing incremental updates later on. In fact, I really like Chuck's idea of breaking the core into components that can be updated separately [1]. I also like his idea of splitting individual packages into core and extra categories, where core contains only what we get from a minimalist installation. This avoids polluting a minimalist installation when doing an in-place update. Best Regards, Cesar [1] MinGW user list Re: autoconf for msys, by Charles Wilson http://article.gmane.org/gmane.comp.gnu.mingw.user/28996 |
From: Earnie B. <ea...@us...> - 2009-03-13 11:18:03
|
Quoting Cesar Strauss <ces...@gm...>: > Dear MinGW developers, > > It seems to me that MSYS 1.0.11 is currently quite stable, and is > otherwise good enough for general use. I think now is a good time as > any for cutting a stable release. I just need to finish touching up > the release notes, and I will be able to issue a release candidate. > Bring out the fireworks. After five years in development, the first alpha release was in 2004, it should be ready. I have some ideas for 1.0.12 that I will discuss under a different thread. There maybe a branch for it already. > On the other hand, by releasing now, I am temporarily backing up on > the idea of an unified MinGW/MSYS/DTK/ports net-installer/updater. > Instead, I'll use the currently available Inno-based installer of > MSYS-1.0.10. In fact, all the work to update it to 1.0.11 seems to be > in CVS already. > I don't see this as a big problem. > This being over, I do intend to work on the installer. I think I'll > begin to put together a gui-independent library to deal with unpacking > tarballs, checking for updates, making downloads, following > dependencies, reading config files, etc. > Maybe an XML parser and the config files would be written in XML. > As for the near future, some MSYS tools still have very old versions > that could be updated in the short term (e.g., sed and grep). They > could be dealt with by doing incremental updates later on. In fact, I > really like Chuck's idea of breaking the core into components that can > be updated separately [1]. > > I also like his idea of splitting individual packages into core and > extra categories, where core contains only what we get from a > minimalist installation. This avoids polluting a minimalist > installation when doing an in-place update. > > Best Regards, > Cesar > > [1] > MinGW user list > Re: autoconf for msys, by Charles Wilson > http://article.gmane.org/gmane.comp.gnu.mingw.user/28996 > I like this as well. Earnie |
From: Keith M. <kei...@us...> - 2009-03-13 17:26:50
|
On Friday 13 March 2009 03:31:58 Cesar Strauss wrote: > It seems to me that MSYS 1.0.11 is currently quite stable, and is > otherwise good enough for general use. I think now is a good time > as any for cutting a stable release. I just need to finish touching > up the release notes, and I will be able to issue a release > candidate. This is good news. I do have one outstanding bug-fix, for the which script; I'll try to get that into CVS, this weekend. There is also the outstanding issue of the rxvt vs. norxvt preference in msys.bat. This has come up a number of times, on the users lists, and, owing to the continuing problems in the rxvt support, there was a general preference expressed, to reverse the default choice, to make rxvt optional, with the norxvt mode selected as default. We said we would accommodate that preference, when we came to release MSYS-1.0.11, so I guess now is the time to do so. I'll address that too, if you wish. > On the other hand, by releasing now, I am temporarily backing up on > the idea of an unified MinGW/MSYS/DTK/ports net-installer/updater. > Instead, I'll use the currently available Inno-based installer of > MSYS-1.0.10. In fact, all the work to update it to 1.0.11 seems to > be in CVS already. Ultimately, we should deliver it via mingw-get, but that's too far off for an immediate release. I have no objection to sticking with the Inno-based installer, if it helps us to get MSYS-1.0.11 out of the door in quick order. > This being over, I do intend to work on the installer. I think I'll > begin to put together a gui-independent library to deal with > unpacking tarballs, checking for updates, making downloads, > following dependencies, reading config files, etc. This makes a lot of sense, but please don't abandon the concepts that John E. has already begun to implement; (there is also the proof of concept WX demo that I put together, which I think might be worth adding to it's own branch, within the mingw-get CVS module -- it isn't really suitable for the final product, because it carries a significant code bloat, but I find it very useful for prototyping). Earnie has already suggested XML, and I agree; that's the basis both John and I have chosen to map the repository, describing the package affiliations and interdependencies. FWIW, in my prototype, the package grouping, layout, inter-relationships and descriptions, are completely and flexibly described in XML, and John has adopted a similar design goal. > As for the near future, some MSYS tools still have very old > versions that could be updated in the short term (e.g., sed and > grep). They could be dealt with by doing incremental updates later > on. In fact, I really like Chuck's idea of breaking the core into > components that can be updated separately [1]. Yes, I do too. Indeed, a similar line of thinking led me to my conceptual design for mingw-get. > I also like his idea of splitting individual packages into core and > extra categories, where core contains only what we get from a > minimalist installation. This avoids polluting a minimalist > installation when doing an in-place update. Agreed; however, I would prefer the term `base' to `core', and `full' to `extra', (with a `full' package being a superset of the equivalent `base', i.e. `full' is everything the upstream package would provide, while `base' is the minimal subset of that, needed to provide a level of functionality matching that of present MSYS-1.0.10). Thus, we might have, (for example): bash-3.1-msys-base-1.0.11-bin.tar.{gz|bz2|lzma} bash-3.1-msys-full-1.0.11-bin.tar.{gz|bz2|lzma} bash-3.1-msys-1.0.11-src.tar.{gz|bz2|lzma} : [etc...] and the installer would deliver the aggregate of the *msys-base-*-bin* packages, as needed for the minimal base system installation, while leaving the user the subsequent freedom to choose to add any of the *msys-full-*-bin* packages he might like, in whatever incremental steps he might consider to be appropriate to his own needs. -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2009-03-13 18:12:25
|
First, I'm glad to see some movement on this front. Thanks, Cesar. Keith Marshall wrote: > Agreed; however, I would prefer the term `base' to `core', and `full' > to `extra', (with a `full' package being a superset of the equivalent > `base', i.e. `full' is everything the upstream package would provide, > while `base' is the minimal subset of that, needed to provide a level > of functionality matching that of present MSYS-1.0.10). Thus, we > might have, (for example): > > bash-3.1-msys-base-1.0.11-bin.tar.{gz|bz2|lzma} > bash-3.1-msys-full-1.0.11-bin.tar.{gz|bz2|lzma} > bash-3.1-msys-1.0.11-src.tar.{gz|bz2|lzma} > : > [etc...] > > and the installer would deliver the aggregate of the *msys-base-*-bin* > packages, as needed for the minimal base system installation, while > leaving the user the subsequent freedom to choose to add any of the > *msys-full-*-bin* packages he might like, in whatever incremental > steps he might consider to be appropriate to his own needs. I disagree with this approach, because it assumes that "the rest" will always ALSO be distributed monolithically. That is, your choices seem limited to the (overlapping) pair: foo-*-base-*-bin foo-*-full-*-bin (duplicates stuff in -base-) But what about library packages? If we follow the previously-described guidelines concerning DLLS, then you'd have foo-*-base-*-bin foo-*-base-*-dll foo-*-full-*-bin foo-*-full-*-dll (ex: currently, bzip2 is considered base, but the executables ARE linked dynamically against msys-bzip2-1.dll [actually, it's still called libbz2-1.dll because I haven't gotten around to rebuilding it yet]. Now, MAYBE, the answer is "just ensure the binaries in bzip2-*-base-*-bin are statically linked, then you don't need bzip2-base-*-dll, only bzip2-extra-*-dll. But what you're REALLY saying is that our package naming convention is not flexible enough to satisfy all possible scenarios; we'd rather restrict the scenarios by imposing additional requirements on the package maintainers). Anyway, back to the list above: first, foo-*-full-*-bin isn't really "full" now is it? It doesn't contain EVERYTHING -- because that conflicts with the other packaging guidelines concerning DLLs. Secondly, what is the difference between foo-*-full-*-dll and foo-*-base-*-dll? Nothing. So, you then have foo-*-base-*-bin foo-*-base-*-dll foo-*-full-*-bin But a "full" installation requires foo-full-bin + foo-BASE-dll? Once again, "full" isn't really full. "Full" is a bad name. Plus, you are deliberately introducing conflicts into package structure. By its very nature, foo-*-base-*-bin conflicts with foo-*-full-*-bin (say, both of them provide foo.exe). If the 'bar' package requires the foo program, which package satisfies it? foo-*-base-*-bin or foo-*-full-*-bin? Why, both do. bar can't specify that it specifically requires one or the other (because that would force the end user to install specifically one or the other according to however the 'bar' maintainer wrote the XML; the end user wouldn't be able to pick, on her own, which of the two she wanted to use). To allow her to do this, the XML scheme and the installer program would have to support "virtual" requirements: on things that are not themselves packages. e.g bar-*-bin : requires foo.exe Because of this, you not only have to support conflicts-with specifications in your package descriptions (XML), but also "provides" specifications, so that the virtual 'foo.exe' requirement of 'bar' can be satisfied by either 'foo-*-base-*-bin' or 'foo-*-full-*-bin'. e.g. foo-*-base-*-bin : provides foo.exe, conflicts-with foo-full-bin foo-*-full-*-bin : provides foo.exe, conflicts-with foo-base-bin This is a much harder than it needs to be, and the logic for handling this is going to be prone to bugs. (Plus, it requires more effort on the part of individual package maintainers -- if we have such persons -- to get the XML "right" for their package. Experience on cygwin shows that it is hard enough for everyone, without fail, to get the simple stuff in cygwin's setup.hints correct. Never mind complicated stuff.) What's so bad about: foo-*-base-*-dll foo-*-base-*-bin : requires foo-base-dll [++] foo-*-extra-*-bin : requires foo-base-dll, foo-base-bin foo-*-extra-*-doc : <none> foo-*-extra-*-dev : requires foo-base-dll [++] of matching version number (e.g. bash-[[3.1]]-) and system specification (e.g. -[[msys-1.0.11]]-) No "virtual" requirements. No conflicts-with. No provides specification. All requirements are on actual, existing, packages. Heck, you might even have foo-*-extra-*-dll if foo has multiple DLLs, but some are optional. Like tiff (as if tiff would every be included in 'base', but go with me here) provides libtiif-5.dll, but also libtiffxx-5.dll which is a rarely-used C++ wrapper. You might additionally have foo-*-base-*-doc if there were some documentation (licenses, perhaps?) that really ought to be distributed with the binaries in the 'base' installation, separate from the man pages and documentation in the foo-*-extra-*-doc package which many people won't install. But "documentation" is NOT "-bin" material, nor "-dll" material... The "base" installation is everything named *-base-*. A full foo installation is everything named foo-*. No files are simultaneously provided by multiple tarballs of the same version. This is as close as we can get to KISS while still achieving other goals, like separating dlls and exes, and "base" stuff from "everything else". -- Chuck |
From: Keith M. <kei...@us...> - 2009-04-07 20:29:29
Attachments:
msys.bat.diff
|
On Friday 13 March 2009 15:43:36 Keith Marshall wrote: > I do have one outstanding bug-fix, for the which script; I'll try > to get that into CVS, this weekend. I did that. > There is also the outstanding issue of the rxvt vs. norxvt > preference in msys.bat. This has come up a number of times, on > the users lists, and, owing to the continuing problems in the > rxvt support, there was a general preference expressed, to > reverse the default choice, to make rxvt optional, with the > norxvt mode selected as default. We said we would accommodate > that preference, when we came to release MSYS-1.0.11, so I guess > now is the time to do so. I'll address that too, if you wish. For this, I have prepared a patch, attached. Before I commit it, Earnie, was there any particular reason why you wanted $MSYSCON inherited by secondary invocations? Personally, I found that to be more hindrance than help, but since I've started using Console2 to host my MSYS sessions, I no longer use msys.bat anyway, so the issue is irrelevant for me; however, this patch would change that particular behaviour, causing $MSYSCON to be re-evaluated on every individual invocation. Ok to commit? -- Regards, Keith. |
From: Earnie B. <ea...@us...> - 2009-04-08 11:15:59
|
Quoting Keith Marshall <kei...@us...>: > > Ok to commit? > I'm fine with it if Cesar is. -- Earnie |
From: Cesar S. <ces...@gm...> - 2009-04-08 11:59:39
|
Keith Marshall wrote: > On Friday 13 March 2009 15:43:36 Keith Marshall wrote: >> I do have one outstanding bug-fix, for the which script; I'll try >> to get that into CVS, this weekend. > > I did that. Thanks, Keith, I'll include it in the release. I also took note of the missing install-info.exe.manifest file. >> there was a general preference expressed, to >> reverse the default choice, to make rxvt optional, with the >> norxvt mode selected as default. [...] > For this, I have prepared a patch, attached. [...] > > Ok to commit? > Seems fine to me, please go ahead. I updated the installer to create a second shortcut on the Start Menu, named "MSYS (rxvt)". Both shortcuts will use either -norxvt or -rxvt, where appropriate. The shortcut on the Desktop will use -norxvt. Regards, Cesar |
From: Keith M. <kei...@us...> - 2009-04-08 19:32:37
|
On Wednesday 08 April 2009 12:59:28 Cesar Strauss wrote: > >> there was a general preference expressed, to > >> reverse the default choice, to make rxvt optional, with the > >> norxvt mode selected as default. > > [...] > > > For this, I have prepared a patch, attached. > > [...] > > > Ok to commit? > > Seems fine to me, please go ahead. Done. > I updated the installer to create a second shortcut on the Start > Menu, named "MSYS (rxvt)". Both shortcuts will use either -norxvt > or -rxvt, where appropriate. The shortcut on the Desktop will use > -norxvt. Seems like a good solution; should keep everyone happy. -- Regards, Keith. |
From: Keith M. <kei...@us...> - 2009-04-08 16:30:55
|
On Friday 13 March 2009 18:11:56 Charles Wilson wrote: > Keith Marshall wrote: > > Agreed; however, I would prefer the term `base' to `core', and > > `full' to `extra', (with a `full' package being a superset of > > the equivalent `base', i.e. `full' is everything the upstream > > package would provide, while `base' is the minimal subset of > > that, needed to provide a level of functionality matching that > > of present MSYS-1.0.10). Thus, we might have, (for example): > > > > bash-3.1-msys-base-1.0.11-bin.tar.{gz|bz2|lzma} > > bash-3.1-msys-full-1.0.11-bin.tar.{gz|bz2|lzma} > > bash-3.1-msys-1.0.11-src.tar.{gz|bz2|lzma} > > > > [etc...] > > > > and the installer would deliver the aggregate of the > > *msys-base-*-bin* packages, as needed for the minimal base > > system installation, while leaving the user the subsequent > > freedom to choose to add any of the *msys-full-*-bin* packages > > he might like, in whatever incremental steps he might consider > > to be appropriate to his own needs. > > I disagree with this approach, because it assumes that "the rest" > will always ALSO be distributed monolithically. That is, your > choices seem limited to the (overlapping) pair: > > foo-*-base-*-bin > foo-*-full-*-bin (duplicates stuff in -base-) Agreed, overlap is undesirable; how I really visualise the package structure is that `base' would provide the minimal required set of components, while `full' provides the optional extras, and is made, (maybe by the installer), to have a (possibly automatic) dependency on its corresponding `base'. Thus, the user will perceive a single package installation of the `full' class to give him everything, where in reality the installer processes this as two physical packages, `base' + `full'. > But what about library packages? If we follow the > previously-described guidelines concerning DLLS, then you'd have > > foo-*-base-*-bin > foo-*-base-*-dll > foo-*-full-*-bin > foo-*-full-*-dll > > (ex: currently, bzip2 is considered base, but the executables ARE > linked dynamically against msys-bzip2-1.dll [actually, it's still > called libbz2-1.dll because I haven't gotten around to rebuilding > it yet]. Now, MAYBE, the answer is "just ensure the binaries in > bzip2-*-base-*-bin are statically linked, then you don't need > bzip2-base-*-dll, only bzip2-extra-*-dll. But what you're REALLY > saying is that our package naming convention is not flexible > enough to satisfy all possible scenarios; we'd rather restrict > the scenarios by imposing additional requirements on the package > maintainers). I don't think I'm saying that, at all; I believe that the package naming conventions, as we've already discussed them, are completely adequate to our needs. > Anyway, back to the list above: first, foo-*-full-*-bin isn't > really "full" now is it? It doesn't contain EVERYTHING -- Logically, it does if its dependencies are properly defined; a `bin' package needs to specify its complete set of `dll' dependencies, so installing `foo-*-full-*-bin' would be expected to install *all* of: foo-*-msys-base-*-bin foo-*-msys-full-*-bin foo-*-msys-base-*-dll-* (appropriate version, as required) foo-*-msys-full-*-dll-* (ditto, if it is needed at all) or, in those cases where there is no need for any additional `dll' functionality, between `base' and `full', (most, perhaps?), simply: foo-*-msys-base-*-bin foo-*-msys-full-*-bin foo-*-msys-*-dll-* (appropriate version, as required) > because that conflicts with the other packaging guidelines > concerning DLLs. I don't see why, although perhaps it makes more sense if `base' and `full' qualifiers apply to individual packages, rather than to the system as a whole, so we would rather have: foo-base-*-msys-*-bin foo-full-*-msys-*-bin foo-*-msys-*-dll-* (appropriate version, as required) > Secondly, what is the difference between > foo-*-full-*-dll and foo-*-base-*-dll? Nothing. Yes, so you need only the one `dll' package, and there is no need to qualify it as either `base' or `full'; `foo-*-dll' will suffice. > So, you then have > > foo-*-base-*-bin > foo-*-base-*-dll > foo-*-full-*-bin > > But a "full" installation requires foo-full-bin + foo-BASE-dll? > Once again, "full" isn't really full. "Full" is a bad name. Ok, I concede that `extra' may be a better choice than `full', from the perspective of a package maintainer; from the perspective of an end user, perhaps a single installation of a `full' package might just be an easier choice than selecting *both* `base' and `extra'. However, I can live with either choice; my primary preference is for `base' rather than `core'; (the core is the bit of the apple I throw away), but even on that, I won't dig in my heels. > Plus, you are deliberately introducing conflicts into package > structure. By its very nature, foo-*-base-*-bin conflicts with > foo-*-full-*-bin (say, both of them provide foo.exe). Not if the `full' package provides only the components not already present in `base', and has an automatic dependency on `base'. Of course, this really means that `full' is a misnomer for `extra', from the perspective of the maintainer, although not perhaps from the perspective of the end user. > If the 'bar' package requires the foo program, which package > satisfies it? foo-*-base-*-bin or foo-*-full-*-bin? If the dependency can be fully satisfied by the `foo-*-base-*-bin' package alone, then the dependency should be defined as such; of course, if the user has already selected `foo-*-full-*-bin', then that should also suffice, to satisfy the dependency. > Why, both > do. bar can't specify that it specifically requires one or the > other (because that would force the end user to install > specifically one or the other according to however the 'bar' > maintainer wrote the XML; Huh? If `bar' has a declared dependency on `foo-*-base-*-bin', and `foo-*-full-*-bin' also has a dependency on `foo-*-base-*-bin', no matter how that dependency is satisfied, then if `foo-*-full-*-bin' is installed, or selected for installation, then that dependency *must* also be satisfied for `bar'; the `bar' maintainer need only specify that `bar' requires `foo-*-base-*-bin'. > the end user wouldn't be able to pick, > on her own, which of the two she wanted to use). To allow her to > do this, the XML scheme and the installer program would have to > support "virtual" requirements: on things that are not themselves > packages. e.g > > bar-*-bin : requires foo.exe As a concept, virtual *packages* could be very useful: <package name="msys-base" class="virtual"> <affiliate group="MSYS Base System" /> <release version="1.0.11" status="stable"> <requires> <package name="foo" version="7.8.9" match="exact" /> <package name="bar" version="0.1.2" match="least" /> </requires> </release> </package> which the installer would handle as just a list of required packages to install, with nothing more to be added, (although it could maybe also invoke a pre-install and/or post-install script). > Because of this, you not only have to support conflicts-with > specifications in your package descriptions (XML), but also > "provides" specifications, so that the virtual 'foo.exe' > requirement of 'bar' can be satisfied by either > 'foo-*-base-*-bin' or 'foo-*-full-*-bin'. e.g. > > foo-*-base-*-bin : provides foo.exe, conflicts-with > foo-full-bin foo-*-full-*-bin : provides foo.exe, conflicts-with > foo-base-bin OTOH, virtual *requirements* such as this, (where the requirement is not itself a package, either real or virtual), are something we do not want, (as are "provides" specs). > This is a much harder than it needs to be, and the logic for > handling this is going to be prone to bugs. (Plus, it requires > more effort on the part of individual package maintainers -- if > we have such persons -- to get the XML "right" for their package. > Experience on cygwin shows that it is hard enough for everyone, > without fail, to get the simple stuff in cygwin's setup.hints > correct. Never mind complicated stuff.) Agreed. > What's so bad about: > > foo-*-base-*-dll > foo-*-base-*-bin : requires foo-base-dll [++] > foo-*-extra-*-bin : requires foo-base-dll, foo-base-bin > foo-*-extra-*-doc : <none> > foo-*-extra-*-dev : requires foo-base-dll > > [++] of matching version number (e.g. bash-[[3.1]]-) and system > specification (e.g. -[[msys-1.0.11]]-) What's wrong with simply: foo-*-dll foo-*-base-*-bin : requires foo-base-dll [++] foo-*-extra-*-bin : requires foo-dll, foo-base-bin foo-*-doc : <none> foo-*-dev : requires foo-base-dll If there is only one package of a particular component class, why confuse the issue by qualifying it as `base' or `extra', (or `full' as a possible synonym for `extra'); some Smart Alec is sure to ask you where to find, for example, your: foo-*-base-*-doc package, when you give him the hint that the package you do provide is an *extra* documentation package, (in this case `full' actually does make more sense than `extra', whatever way you look at it). > The "base" installation is everything named *-base-*. A full foo > installation is everything named foo-*. No files are > simultaneously provided by multiple tarballs of the same version. > This is as close as we can get to KISS while still achieving > other goals, like separating dlls and exes, and "base" stuff from > "everything else". That, of course, is the ultimate goal. I think, in reality, that we have very similar ideas, but a difference in perception; you are arguing from the perspective of a developer; I am trying to identify with the perception of an end user. As long as we end up with appropriate *functionality*, let's not fall out over the choice of words we use to describe it. -- Regards, Keith. |
From: Earnie B. <ea...@us...> - 2009-04-09 11:11:07
|
Quoting Keith Marshall <kei...@us...>: > > Ok, I concede that `extra' may be a better choice than `full', from > the perspective of a package maintainer; from the perspective of an > end user, perhaps a single installation of a `full' package might > just be an easier choice than selecting *both* `base' and `extra'. > However, I can live with either choice; my primary preference is > for `base' rather than `core'; (the core is the bit of the apple I > throw away), but even on that, I won't dig in my heels. > Good, because in other projects where I've seen similar naming -full means everything in one bucket. A qualifier of -extra is much more meaningful especially for those not using an automated installer and unpacking it themselves. -- Earnie |