From: John E. / T. <td...@td...> - 2008-08-04 22:00:16
|
Hi, folks! You may or may not recall that, back in January of this year, I expressed interest in reworking the MinGW installer (<http://article.gmane.org/gmane.comp.gnu.mingw.user/25012>). Several other projects I'd been working on are now finished, my plate is emptier, and I'm now ready to submit a more solid proposal, for consideration by MinGW's users and developers, to improve the MinGW installer. As mentioned in the message linked above, I have created a versioned-component management system on top of NSIS that is more feature-rich than the standard NSIS installer. Here are some of its features: * Component descriptors and installation manifests use XML * Discriminatory uninstallation: only remove files installed by the setup program * Support online-only or online/offline installers with inner components * Download latest descriptor file to determine available components * Update to newer component versions by automatically removing the old version, then installing the new version * Let users select from multiple download mirrors * Unpack zip archives, gzip and bzip2 tarballs, and 7-zip archives, maintaining original file attributes * Download component archives with resume capability (uses the Inetc plugin for NSIS) * Track multiple installations * No registry entries created * Multiuser-environment-friendly This system is currently in use in a new installer, released two days ago (August 2nd), for my unofficial GCC builds for MinGW. The installer can be downloaded from <http://www.tdragon.net/recentgcc/>, and the source code is available at <http://downloads.sourceforge.net/tdm-gcc/tdminstall-1.808.1.zip>. A minimum of modification should be necessary to convert these sources into an official installer for the MinGW project. Therefore, I propose that this installation system be used as (or as a base for) a new MinGW installer, subject to your critique. Should my proposal be accepted, I'm also willing to provide any level of maintenance in continuance on the installer deemed appropriate. The installer system is obviously at a usable and (hopefully) mainly bug-free level of functionality currently, but I will be working on it in the following minor areas in the immediate future: * Documenting the code (*grin*) * Improving the UI for component and version selection (current tree view feels too cluttered/clunky; need ideas...) Your response appreciated, John E. |
From: Earnie B. <ea...@us...> - 2008-08-05 12:26:25
|
Quoting "John E. / TDM" <td...@td...>: > Hi, folks! > Hi John, The first comment is to please don't cross post between users and dvlpr. We admins will just have to delete the invalid posts to dvlpr. > You may or may not recall that, back in January of this year, I > expressed interest in reworking the MinGW installer > (<http://article.gmane.org/gmane.comp.gnu.mingw.user/25012>). Several > other projects I'd been working on are now finished, my plate is > emptier, and I'm now ready to submit a more solid proposal, for > consideration by MinGW's users and developers, to improve the MinGW > installer. > I'm excited to hear this. > As mentioned in the message linked above, I have created a > versioned-component management system on top of NSIS that is more > feature-rich than the standard NSIS installer. Here are some of its > features: > * Component descriptors and installation manifests use XML > * Discriminatory uninstallation: only remove files installed by the setup > program > * Support online-only or online/offline installers with inner components > * Download latest descriptor file to determine available components > * Update to newer component versions by automatically removing the old > version, > then installing the new version > * Let users select from multiple download mirrors > * Unpack zip archives, gzip and bzip2 tarballs, and 7-zip archives, > maintaining > original file attributes > * Download component archives with resume capability (uses the Inetc > plugin for > NSIS) > * Track multiple installations > * No registry entries created > * Multiuser-environment-friendly > > This system is currently in use in a new installer, released two days > ago (August 2nd), for my unofficial GCC builds for MinGW. The installer > can be downloaded from <http://www.tdragon.net/recentgcc/>, and the > source code is available at > <http://downloads.sourceforge.net/tdm-gcc/tdminstall-1.808.1.zip>. > NSIS is nice, modular and extensible. If no registry entries are created (a plus in my book) how do you manage undeletes? > A minimum of modification should be necessary to convert these sources > into an official installer for the MinGW project. Therefore, I propose > that this installation system be used as (or as a base for) a new MinGW > installer, subject to your critique. Should my proposal be accepted, I'm > also willing to provide any level of maintenance in continuance on the > installer deemed appropriate. > I think we can allow the community to decide this so users is the best place for discussion. Let's upload what you have into CVS for easy review by others. I would like to hear from Keith since I know he has ideas as well. > The installer system is obviously at a usable and (hopefully) mainly > bug-free level of functionality currently, but I will be working on it > in the following minor areas in the immediate future: > * Documenting the code (*grin*) > * Improving the UI for component and version selection (current tree > view feels too cluttered/clunky; need ideas...) > Again we should upload to CVS or even SVN so that others can help review and comment. I would like this installer to be all encompassing and know what is dependent on what and be able to install the dependencies with the primary package. Also, we would use it for both MinGW and MSYS. Earnie |
From: Keith M. <kei...@us...> - 2008-08-06 05:15:29
|
On Tuesday 05 August 2008 13:26:16 Earnie Boyd wrote: > > A minimum of modification should be necessary to convert these > > sources into an official installer for the MinGW project. > > Therefore, I propose that this installation system be used as (or > > as a base for) a new MinGW installer, subject to your critique. > > Should my proposal be accepted, I'm also willing to provide any > > level of maintenance in continuance on the installer deemed > > appropriate. > > I think we can allow the community to decide this so users is the > best place for discussion. I agree. All technical discussion is best kept on MinGW-Users, with MinGW-Dvlpr being reserved for mainly policy discussion. > Let's upload what you have into CVS for > easy review by others. I would like to hear from Keith since I know > he has ideas as well. I would like to see something similar to Synaptic, (as used by Ubuntu), with a three pane display:-- 1) A tree view of package `collections', e.g. `MinGW Base', `MinGW Extras', `MSYS Base', etc. 2) A list view of packages included within the active selection in (1); this should indicate package availability, by version, and also what is already installed, again by version. 3) A description for the active selection in (2). Associated with this, should be menu or tool-bar options to install, (first-time), update, (to a newer version), revert, (to an earlier version), or to remove an existing installation, for the active selection in (2), together with any prerequisites, (in the case of installation or update), or dependents, (for removal, after warning and user confirmation, when removing a package with dependents). > > The installer system is obviously at a usable and (hopefully) > > mainly bug-free level of functionality currently, but I will be > > working on it in the following minor areas in the immediate future: > > * Documenting the code (*grin*) > > * Improving the UI for component and version selection (current > > tree view feels too cluttered/clunky; need ideas...) > > Again we should upload to CVS... Yes please. > or even SVN... No thank you; we already have everything else in CVS, and I have enough on my plate already, without having to consider a migration to YAVCS. > so that others can help review and comment. We could also consider the feature request tracker, although it is a pain that it allows only the initiator, or an administrator, to attach sample files. > I would like this installer to be all > encompassing and know what is dependent on what and be able to > install the dependencies with the primary package. Also, we would > use it for both MinGW and MSYS. Yes, definitely. Possibly also as a front end for mingwPORT. Regards, Keith. |
From: Keith M. <kei...@us...> - 2008-08-06 05:44:32
|
On Wednesday 06 August 2008 06:15:18 Keith Marshall wrote: > I would like to see something similar to Synaptic... http://www.nongnu.org/synaptic/action.html Regards, Keith. |
From: Earnie B. <ea...@us...> - 2008-08-06 13:40:09
|
Quoting Keith Marshall <kei...@us...>: > On Wednesday 06 August 2008 06:15:18 Keith Marshall wrote: >> I would like to see something similar to Synaptic... > > http://www.nongnu.org/synaptic/action.html > Is there a windows build that is distributed somewhere? I couldn't find one. Earnie |
From: JonY <10...@gm...> - 2008-08-06 15:13:34
|
Earnie Boyd wrote: > Quoting Keith Marshall<kei...@us...>: > >> On Wednesday 06 August 2008 06:15:18 Keith Marshall wrote: >>> I would like to see something similar to Synaptic... >> http://www.nongnu.org/synaptic/action.html >> > > Is there a windows build that is distributed somewhere? I couldn't find one. > > Earnie > Perhaps Keith meant that the GUI should look like Synaptic. |
From: Earnie B. <ea...@us...> - 2008-08-06 16:20:12
|
Quoting JonY <10...@gm...>: > Earnie Boyd wrote: >> Quoting Keith Marshall<kei...@us...>: >> >>> On Wednesday 06 August 2008 06:15:18 Keith Marshall wrote: >>>> I would like to see something similar to Synaptic... >>> http://www.nongnu.org/synaptic/action.html >>> >> >> Is there a windows build that is distributed somewhere? I couldn't >> find one. >> >> Earnie >> > > Perhaps Keith meant that the GUI should look like Synaptic. > In my research Synaptic was running on windows but I don't know if it required Cygwin or not. If Synaptic runs on windows then why not just build the scripts for it to use? It may require a sh.exe though which isn't exactly what we want. Earnie |
From: JonY <10...@gm...> - 2008-08-07 04:00:07
|
Earnie Boyd wrote: > Quoting JonY<10...@gm...>: > >> Earnie Boyd wrote: >>> Quoting Keith Marshall<kei...@us...>: >>> >>>> On Wednesday 06 August 2008 06:15:18 Keith Marshall wrote: >>>>> I would like to see something similar to Synaptic... >>>> http://www.nongnu.org/synaptic/action.html >>>> >>> Is there a windows build that is distributed somewhere? I couldn't >>> find one. >>> >>> Earnie >>> >> Perhaps Keith meant that the GUI should look like Synaptic. >> > > In my research Synaptic was running on windows but I don't know if it > required Cygwin or not. If Synaptic runs on windows then why not just > build the scripts for it to use? It may require a sh.exe though which > isn't exactly what we want. > > Earnie > Hi, Synaptic is a GUI frontend for apt. It also needs GTK+-2 and friends at runtime. It seems like an installer using Synaptic is inadvisable, too much bloat IMHO. |
From: Keith M. <kei...@us...> - 2008-08-06 22:14:47
|
On Wednesday 06 August 2008 14:39:58 Earnie Boyd wrote: > > On Wednesday 06 August 2008 06:15:18 Keith Marshall wrote: > >> I would like to see something similar to Synaptic... > > > > http://www.nongnu.org/synaptic/action.html > > Is there a windows build that is distributed somewhere? I couldn't > find one. None that I know of; synaptic is very much a GUI for Debian's apt-get and dpkg tools, so it is mostly found in Debian-derived Linux distros. The majority of the Google hits I found for `synaptic package manager windows' were Ubuntu focussed. I did find this one link: http://www.sizlopedia.com/2008/08/02/qwinapt-package-manager-for-windows/ but the firewall at work blocked the download, so I didn't get to try it; I'll have a look tomorrow, after downloading at home. Anyway, I wasn't suggesting that we should use synaptic as such, nor even that it should look like it, but that something exhibiting similar core functionality would be a good objective to strive for. Regards, Keith. |
From: Earnie B. <ea...@us...> - 2008-08-06 12:54:23
|
Quoting Keith Marshall <kei...@us...>: > >> or even SVN... > > No thank you; we already have everything else in CVS, and I have enough > on my plate already, without having to consider a migration to YAVCS. > I'm not going to argue for this but just want to state the SVN is very much similar to CVS with its major difference in branching and release tags. While I will not consider a migration of current CVS to SVN; I would consider adding new items to SVN based on your agreement. cvs -d repository checkout -d dir svn checkout repository dir cvs diff svn diff cvs update svn update cvs commit -m'foo bar' svn commit -m'foo bar' cvs stat svn stat Earnie |
From: John E. / T. <td...@td...> - 2008-08-06 15:29:59
|
Keith Marshall wrote: > I would like to see something similar to Synaptic, (as used by Ubuntu), > with a three pane display:-- > > 1) A tree view of package `collections', e.g. `MinGW Base', `MinGW > Extras', `MSYS Base', etc. > > 2) A list view of packages included within the active selection in (1); > this should indicate package availability, by version, and also what is > already installed, again by version. > > 3) A description for the active selection in (2). > > Associated with this, should be menu or tool-bar options to install, > (first-time), update, (to a newer version), revert, (to an earlier > version), or to remove an existing installation, for the active > selection in (2), together with any prerequisites, (in the case of > installation or update), or dependents, (for removal, after warning and > user confirmation, when removing a package with dependents). > Well, you certainly aren't limiting your vision... What you describe shares a relatively small amount of code with my proposal -- perhaps 20% of what I've written would be used -- and would be at least two or three times as much code. This is well and good in that what you describe provides more (and better) functionality, but it does mean a much longer wait before the product is usable (indeterminately long, if I am the only contributor). It would mean taking the design all the way back to the stage of evaluating middleware/APIs to base it on. Nevertheless I am willing to work on this if there is general agreement that it is appropriate. >> Again we should upload to CVS... >> > > Yes please. > I can certainly do this. >> or even SVN... >> > > No thank you; we already have everything else in CVS, and I have enough > on my plate already, without having to consider a migration to YAVCS. > ...and I track everything locally with Mercurial anyway. Cheers, John E. |
From: John E. / T. <td...@td...> - 2008-08-05 13:55:01
|
Earnie Boyd wrote: > The first comment is to please don't cross post between users and > dvlpr. We admins will just have to delete the invalid posts to dvlpr. > Sure. > NSIS is nice, modular and extensible. If no registry entries are > created (a plus in my book) how do you manage undeletes? > Now that you bring it up, I need to amend that to "the only registry entry created is for an entry in Windows' Add/Remove Programs". But everything else is stored in files -- a manifest of installed components and files for each installation is kept in the root of the installation directory, and a list of installations is kept in the user's Application Data folder. > I think we can allow the community to decide this so users is the best > place for discussion. Let's upload what you have into CVS for easy > review by others. I would like to hear from Keith since I know he has > ideas as well. > ... > Again we should upload to CVS or even SVN so that others can help > review and comment. Yes, SVN would definitely be preferable to me. > I would like this installer to be all encompassing > and know what is dependent on what and be able to install the > dependencies with the primary package. Also, we would use it for both > MinGW and MSYS. > Dependency tracking is not currently implemented as it didn't seem necessary for non-MSYS installations, but I can certainly see that it would be useful for MSYS components. I'll add it to the list. -John E. |
From: Earnie B. <ea...@us...> - 2008-08-06 13:03:22
|
Quoting "John E. / TDM" <td...@td...>: > > Dependency tracking is not currently implemented as it didn't seem > necessary for non-MSYS installations, but I can certainly see that it > would be useful for MSYS components. I'll add it to the list. > Dependency tracking is even needed for MinGW. Someone decides he wants g++ but doesn't yet have gcc-core he will need that. And gcc-core is really dependent on mingw-runtime and w32api to be useful. Earnie |
From: Keith M. <kei...@us...> - 2008-08-06 21:48:30
|
On Wednesday 06 August 2008 14:03:15 Earnie Boyd wrote: > > Dependency tracking is not currently implemented as it didn't seem > > necessary for non-MSYS installations, but I can certainly see that > > it would be useful for MSYS components. I'll add it to the list. > > Dependency tracking is even needed for MinGW. Someone decides he > wants g++ but doesn't yet have gcc-core he will need that. And > gcc-core is really dependent on mingw-runtime and w32api to be > useful. Not to mention binutils, which could be used stand alone, but is a definite prerequisite for gcc-core. Regards, Keith. |
From: Earnie B. <ea...@us...> - 2008-08-06 13:24:44
|
Quoting "John E. / TDM" <td...@td...>: > > Yes, SVN would definitely be preferable to me. > Keith said no, so, unless he changes his mind, it will be CVS. Earnie |
From: Earnie B. <ea...@us...> - 2008-08-06 13:28:45
|
Quoting "John E. / TDM" <td...@td...>: > ... >> Again we should upload to CVS or even SVN so that others can help >> review and comment. > > Yes > What should we call the package? I don't want to call it MinGW, too many people are confused what that means. How about minstall? Earnie |
From: Keith M. <kei...@us...> - 2008-08-06 21:51:45
|
On Wednesday 06 August 2008 14:24:37 Earnie Boyd wrote: > > Yes, SVN would definitely be preferable to me. > > Keith said no, so, unless he changes his mind, it will be CVS. We already have fragmentation of our repositories, with runtime and w32api hosted on sourceware.org, and the rest on sourceforge.net. I'm reluctant to fragment them further, by introducing a different VCS. Regards, Keith. |
From: Earnie B. <ea...@us...> - 2008-08-07 12:59:51
|
Quoting Keith Marshall <kei...@us...>: > On Wednesday 06 August 2008 14:24:37 Earnie Boyd wrote: >> > Yes, SVN would definitely be preferable to me. >> >> Keith said no, so, unless he changes his mind, it will be CVS. > > We already have fragmentation of our repositories, with runtime and > w32api hosted on sourceware.org, and the rest on sourceforge.net. I'm > reluctant to fragment them further, by introducing a different VCS. > I understand and can support this decision. What we need now is a name, mpkg sounds good. Anyone else with an opinion? Earnie |
From: Keith M. <kei...@us...> - 2008-08-06 21:55:53
|
On Wednesday 06 August 2008 14:28:40 Earnie Boyd wrote: > What should we call the package? I don't want to call it MinGW, too > many people are confused what that means. How about minstall? Will it just be an bare bones installer? Or a package manager? I'd thought of mpkg, or mingpkg. Regards, Keith. |
From: Stephen L. <sld...@so...> - 2008-08-07 07:46:33
|
"John E. / TDM" <td...@td...> wrote: > Now that you bring it up, I need to amend that to "the only registry > entry created is for an entry in Windows' Add/Remove Programs". But > everything else is stored in files -- a manifest of installed components > and files for each installation is kept in the root of the installation > directory, and a list of installations is kept in the user's Application > Data folder. Err... May I ask why? If you want to make the install system-wide, you shouldn't need to store informatin in the user's Application Data folder. If you want to make the install per-user, then a global Add/Remove Programs entry is not appropriate. (I don't think there are per-user entries for this, correct me if I am wrong) Stephen -- Stephen Lee <sld...@so...> |
From: John E. / T. <td...@td...> - 2008-08-07 15:43:52
|
Stephen Lee wrote: > "John E. / TDM" <td...@td...> wrote: > >> Now that you bring it up, I need to amend that to "the only registry >> entry created is for an entry in Windows' Add/Remove Programs". But >> everything else is stored in files -- a manifest of installed components >> and files for each installation is kept in the root of the installation >> directory, and a list of installations is kept in the user's Application >> Data folder. >> > > Err... May I ask why? > > If you want to make the install system-wide, you shouldn't need to > store informatin in the user's Application Data folder. > You misunderstand me. The installer does support both system-wide and per-user installations, and tracks up to two separate lists of installations per program instance -- system-wide installations (IFF the user has system-wide access rights) and current-user installations. The list of system-wide installations is stored in the "All Users" Application Data folder, and lists of current-user installations are stored in the users' specific Application Data folder. On pre-Win2K systems, everything defaults to system-wide. And all of the above happens with the help of NSIS' MultiUser.nsh. > If you want to make the install per-user, then a global Add/Remove > Programs entry is not appropriate. (I don't think there are per-user > entries for this, correct me if I am wrong) > You are wrong, in the case of 2k, XP and Vista. -John E. |
From: John E. / T. <td...@td...> - 2008-08-07 15:47:09
|
Earnie Boyd wrote: > Quoting Keith Marshall <kei...@us...>: > >> Will it just be an bare bones installer? Or a package manager? I'd >> thought of mpkg, or mingpkg. >> >> > > I like mpkg; anyone else want to express their opinion? > "mpkg" is already taken. "ming[w]pkg" is my vote. -John E. |
From: Earnie B. <ea...@us...> - 2008-08-08 14:13:11
|
Quoting "John E. / TDM" <td...@td...>: > Earnie Boyd wrote: >> Quoting Keith Marshall <kei...@us...>: >> >>> Will it just be an bare bones installer? Or a package manager? I'd >>> thought of mpkg, or mingpkg. >>> >>> >> >> I like mpkg; anyone else want to express their opinion? >> > > "mpkg" is already taken. "ming[w]pkg" is my vote. > There's no trademark for mpkg and is used by many projects in many different ways. However, I can live with mingwpkg or mingwPKG. Anyone else? Earnie |
From: Joel C. S. <joe...@gm...> - 2008-08-06 15:03:18
|
On Wed, Aug 6, 2008 at 1:44 AM, Keith Marshall <kei...@us...> wrote: > I would like to see something similar to Synaptic... > > http://www.nongnu.org/synaptic/action.html Or perhaps the MiKTeX installer, which handles dependencies as well as multiple mirrors. --Joel |
From: Earnie B. <ea...@us...> - 2008-08-06 16:35:55
|
Quoting "Joel C. Salomon" <joe...@gm...>: > On Wed, Aug 6, 2008 at 1:44 AM, Keith Marshall > <kei...@us...> wrote: >> I would like to see something similar to Synaptic... >> >> http://www.nongnu.org/synaptic/action.html > > Or perhaps the MiKTeX installer, which handles dependencies as well as > multiple mirrors. > I don't think it is quite ready for us yet. http://miktex.org/unx/Default.aspx Earnie |