From: Earnie B. <ea...@us...> - 2007-01-09 14:52:25
|
I need to discuss the design of the installer in support for the addition of using it to also install MSYS. My plan is to create a 1.0.11 release candidate as MSYS-1.0.11-core-rc1.tar.bz2 where core includes all of the files that are currently distributed in the current MSYS installer. Dave, I need to understand why you chose to skip the selection sections of an already chosen Current vs Candidate, etc. I would like to be able to use the MinGW installer to install a Current version as well as a Candidate version. With MSYS 1.0.11 it is possible to install the MinGW GCC and friends into the MSYS /bin directory or vice versa. As a matter of fact I prefer it that way. I know that Keith has stated that he likes the keep it separate method installing GCC and friends into /mingw and installing MSYS into /msys. But if we use the same installer it may be better to enforce the same directory method. Comments? Earnie Boyd -- Please post responsibly: * Use text posts instead of html; many list members just trash mail with html. * Do not use multipart mime to send both text and html versions. * Do not top post replies; post inline with the parts you are responding to. * Trim the post replies; remove irrelevant information from the quoted article. * Original posters: ** Provide small complete examples of the problem. ** Provide the full command that produced errors. ** Provide the versions of the software used. |
From: Earnie B. <ea...@us...> - 2007-01-15 15:45:29
|
Resending for Dave Murphy's eyes. ----- Forwarded message from ea...@us... ----- Date: Tue, 09 Jan 2007 09:52:21 -0500 From: Earnie Boyd <ea...@us...> Reply-To: MinGW Devlopers Discussion List <min...@li...> Subject: [MinGW-dvlpr] MinGW Installer To: min...@li... I need to discuss the design of the installer in support for the addition of using it to also install MSYS. My plan is to create a 1.0.11 release candidate as MSYS-1.0.11-core-rc1.tar.bz2 where core includes all of the files that are currently distributed in the current MSYS installer. Dave, I need to understand why you chose to skip the selection sections of an already chosen Current vs Candidate, etc. I would like to be able to use the MinGW installer to install a Current version as well as a Candidate version. With MSYS 1.0.11 it is possible to install the MinGW GCC and friends into the MSYS /bin directory or vice versa. As a matter of fact I prefer it that way. I know that Keith has stated that he likes the keep it separate method installing GCC and friends into /mingw and installing MSYS into /msys. But if we use the same installer it may be better to enforce the same directory method. Comments? Earnie Boyd -- Please post responsibly: * Use text posts instead of html; many list members just trash mail with html. * Do not use multipart mime to send both text and html versions. * Do not top post replies; post inline with the parts you are responding to. * Trim the post replies; remove irrelevant information from the quoted article. * Original posters: ** Provide small complete examples of the problem. ** Provide the full command that produced errors. ** Provide the versions of the software used. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ MinGW-dvlpr mailing list Min...@li... https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr ----- End forwarded message ----- |
From: Chris S. <ir0...@gm...> - 2007-01-15 16:25:52
|
I was wondering if in general we could not create an 'advanced' install, where users could pick which of the 'current', 'candidate' and 'previous' packages they wanted to install. As Keith mentioned, for some reason when I gave the installer a spin it choose the 'current' binutils as opposed to the 'candidate' binutils, despite the fact I selected a 'candidate' install. Chris -- Chris Sutcliffe http://ir0nh34d.googlepages.com http://ir0nh34d.blogspot.com http://emergedesktop.org |
From: Keith M. <kei...@us...> - 2007-01-15 19:59:46
|
On Monday 15 January 2007 16:25, Chris Sutcliffe wrote: > I was wondering if in general we could not create an 'advanced' > install, where users could pick which of the 'current', 'candidate' > and 'previous' packages they wanted to install. As Keith mentioned, > for some reason when I gave the installer a spin it choose the > 'current' binutils as opposed to the 'candidate' binutils, despite the > fact I selected a 'candidate' install. I believe that the problem here lies in the package versions specified in the installer's `.ini' file; for `binutils', the specified versions do not match their counterparts on the download site, for *any* of the three supported installation categories; (all appear to lag by one release cycle). We really need better co-ordination between the respective package maintainers and Dave, to ensure that the installer is kept in sync with package releases. The same applies for x86-mingw32-build.sh.conf, (which specifies only the equivalent of the `candidate' package set at present), to ensure that the linux-x-mingw32 cross compiler suite is kept up to date; until now, I've been maintaining this package myself; Michael, as you share an interest in it, would you care to take it under your wing? Regards, Keith. |
From: Michael G. <mg...@te...> - 2007-01-16 07:04:58
|
> We really need better co-ordination between the respective package mainta= iners=20 > and Dave, to ensure that the installer is kept in sync with package relea= ses. =20 > The same applies for x86-mingw32-build.sh.conf, (which specifies only the= =20 > equivalent of the `candidate' package set at present), to ensure that the= =20 > linux-x-mingw32 cross compiler suite is kept up to date; until now, I've = been=20 > maintaining this package myself; Michael, as you share an interest in it,= =20 > would you care to take it under your wing? I'm happy to maintain whatever shell programming and (on openSuSE) and to a limited extend testing in environments other than openSuSE (via VMware server) is required, last not least because I can argue this being part of my daily job... ;-) Do we have an infrastructure to collect ideas and wishes for improvements (I'd think we have, have we) ? Best, Michael =2D-=20 Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: mg...@te... GPG-keys available on request or at public keyserver |
From: Earnie B. <ea...@us...> - 2007-01-15 20:46:16
|
Quoting Keith Marshall <kei...@us...>: > > We really need better co-ordination between the respective package > maintainers > and Dave, to ensure that the installer is kept in sync with package releases. If the package maintainer would also update the CVS version of mingw.ini it would be updated in the htdocs directory once every four hours via a cron script running in the mingw shell user account. The installer downloads from http://www.mingw.org/mingw.ini if it exists and it now does. The installer should check its default INI version to make sure that the downloaded file is greater than or equal to it. If not, it should use the default embedded file. Earnie Boyd -- Please post responsibly: * Use text posts instead of html; many list members just trash mail with html. * Do not use multipart mime to send both text and html versions. * Do not top post replies; post inline with the parts you are responding to. * Trim the post replies; remove irrelevant information from the quoted article. * Original posters: ** Provide small complete examples of the problem. ** Provide the full command that produced errors. ** Provide the versions of the software used. |
From: Keith M. <kei...@us...> - 2007-01-15 22:45:59
|
On Monday 15 January 2007 20:46, Earnie Boyd wrote: > > We really need better co-ordination between the respective package > > maintainers > > and Dave, to ensure that the installer is kept in sync with package > > releases. > > If the package maintainer would also update the CVS version of > mingw.ini it would be updated in the htdocs directory once every four > hours via a cron script running in the mingw shell user account. =A0The > installer downloads from http://www.mingw.org/mingw.ini if it exists > and it now does. =A0The installer should check its default INI version to > make sure that the downloaded file is greater than or equal to it. =A0If > not, it should use the default embedded file. Of course, this would be the ideal scenario, if Danny and Chris are willing= to=20 go that extra mile; similar consideration could also be given to providing= =20 updates for x86-mingw32-build.sh.conf, in like manner. I know it has been mentioned before: the installer includes a size indicato= r,=20 within the `.ini' file, for each package; is it clear to all concerned, how= =20 the correct value should be computed. How would *I* compute it, if I were= =20 building a package release? (I don't have a Win32 box to install on, but I= =20 can still build packages by cross compiling from GNU/Linux, and the install= ed=20 size on `ext3' may not be the same as on `NTFS' or `FAT32'). Regards, Keith. |
From: Chris S. <ir0...@gm...> - 2007-01-15 22:55:15
|
Hey All, > Of course, this would be the ideal scenario, if Danny and Chris are willing to > go that extra mile; similar consideration could also be given to providing > updates for x86-mingw32-build.sh.conf, in like manner. FWIW, I just updated the mingw.ini CVS file to point to the latest make for 'candidate' and 'current'. Since Earnie upgraded my Karma to give me permission to the file, I will be sure to update it when I release new versions of make, w32api and runtime. I've noticed that the binutils isn't up to date either. If there are no other takers I can update them as well. Keith in terms of the number after the filename, it's the size of the *extracted* contents in KB. What I do is grab the size of the tar ball. Cheers! Chris -- Chris Sutcliffe http://ir0nh34d.googlepages.com http://ir0nh34d.blogspot.com http://emergedesktop.org |
From: Keith M. <kei...@us...> - 2007-01-15 23:46:34
|
On Monday 15 January 2007 22:55, Chris Sutcliffe wrote: > Keith in terms of the number after the filename, it's the size of the > *extracted* contents in KB. Yep. That's what I understood. > What I do is grab the size of the tar ball. I presume you mean the size of an *uncompressed* tarball? But is that sufficiently accurate? IIRC, Win32 file systems are horrifically inefficient in their use of disk space; if the tarball includes a large number of files, each of which is significantly smaller than the cluster size, then the total *allocated* disk space on extraction could exceed the aggregate size of the tarball, many times over. I was thinking in terms of unpacking to a virgin local directory, then using `du' to report the aggregate size of all allocated disk blocks, but if I do that on `ext3' I'll get a smaller total than on Win32, firstly because `ext3' has a smaller physical block size, and secondly because it allows block fragmentation, so sharing free space in partially filled blocks among multiple files. (It also does defragmentation `on the fly', to maintain peak performance at all times). Regards, Keith. |
From: Chris S. <ir0...@gm...> - 2007-01-16 01:26:44
|
> > What I do is grab the size of the tar ball. > > I presume you mean the size of an *uncompressed* tarball? But is that > sufficiently accurate? IIRC, Win32 file systems are horrifically inefficient > in their use of disk space; if the tarball includes a large number of files, > each of which is significantly smaller than the cluster size, then the total > *allocated* disk space on extraction could exceed the aggregate size of the > tarball, many times over. Yes, I was referring to the uncompressed tarball. I was originally extracting them and grabbing the folder size, but after numerous tests I found that they ended up being the same size as the uncompressed tarball. In the grand scheme of things, I don't think it's critical, since it just provides an estimate of disk space required for installing that particular package. > I was thinking in terms of unpacking to a virgin local directory, then using > `du' to report the aggregate size of all allocated disk blocks, but if I do > that on `ext3' I'll get a smaller total than on Win32, firstly because `ext3' > has a smaller physical block size, and secondly because it allows block > fragmentation, so sharing free space in partially filled blocks among > multiple files. (It also does defragmentation `on the fly', to maintain peak > performance at all times). I agree that using 'ext3' will more than likely not report the same KB usage as NTFS / FAT. I guess it's a matter of the degree of variation and how critical it is in terms of providing the estimate of disk space used for that package when reported by the installer. Cheers! Chris -- Chris Sutcliffe http://ir0nh34d.googlepages.com http://ir0nh34d.blogspot.com http://emergedesktop.org |
From: Hin-Tak L. <hin...@ya...> - 2007-01-16 22:53:34
|
Keith Marshall wrote: <snipped> > I was thinking in terms of unpacking to a virgin local directory, then using > `du' to report the aggregate size of all allocated disk blocks, but if I do > that on `ext3' I'll get a smaller total than on Win32, firstly because `ext3' > has a smaller physical block size, and secondly because it allows block > fragmentation, so sharing free space in partially filled blocks among > multiple files. (It also does defragmentation `on the fly', to maintain peak > performance at all times). <snipped> (Apology my first post ever is off-topic) I am quite sure ext3 does not do 'defragmentation on the fly'. The answer is in an FAQ - I believe on the e2progs site -: the linux kernel reserve the next x blocks (x=16?) whenever possible during a write to a ext2/ext3 partition, so they are far less likely to get fragmented, but they do. In fact a tool called e2defrag exists (linked from e2progs), and I have personally used it myself a few years ago. There are also at least one commercial ext3 defrag programs I know of as well. The last time I run e2fsck on one of my ext3 partitions it was shown as being 10% fragmented - that partition is where I run a particular p2p program, so it has a lot of large and sparse files which are gradually "filled" out-of-sequence. It says ext3 can be hugely fragmented under some usage, and there is no on-the-fly defragmentation. The only situation where one can say on-the-fly defragmentation is when one runs ext3 on top of LVM or a software RAID; but then the "defragmentation" comes from the LVM or RAID rather than ext2/ext3. Feel free to research on this and seek a 2nd opinion. Hin-Tak ___________________________________________________________ Try the all-new Yahoo! Mail. "The New Version is radically easier to use" The Wall Street Journal http://uk.docs.yahoo.com/nowyoucan.html |
From: Earnie B. <ea...@us...> - 2007-01-17 03:59:41
|
Quoting Hin-Tak Leung <hin...@ya...>: > > (Apology my first post ever is off-topic) Getting back on topic, the installer just needs the count of bytes stated in KB of the unextracted files. The installer will check with the system to see if it has X bytes of room in the file system. The system is the one that is responsible for the answer based on the request. Earnie Boyd -- Please post responsibly: * Use text posts instead of html; many list members just trash mail with html. * Do not use multipart mime to send both text and html versions. * Do not top post replies; post inline with the parts you are responding to. * Trim the post replies; remove irrelevant information from the quoted article. * Original posters: ** Provide small complete examples of the problem. ** Provide the full command that produced errors. ** Provide the versions of the software used. |
From: Dave M. <win...@nt...> - 2007-01-17 11:17:54
|
Earnie Boyd wrote: > Dave, I need to understand why you chose to skip the selection sections > of an already chosen Current vs Candidate, etc. I would like to be > able to use the MinGW installer to install a Current version as well as > a Candidate version. > No particular reason other than I hadn't really considered the possibility of end users wanting to install previous/current/candidate in parallel. > With MSYS 1.0.11 it is possible to install the MinGW GCC and friends > into the MSYS /bin directory or vice versa. As a matter of fact I > prefer it that way. I know that Keith has stated that he likes the > keep it separate method installing GCC and friends into /mingw and > installing MSYS into /msys. But if we use the same installer it may be > better to enforce the same directory method. > > Comments Wouldn't it be better to have separate directories if we want to support parallel installs of previous/current/candidate? I know it's possible to have multiple versions of gcc share the same directory but I'm not sure if the same holds true of binutils and the win32 support libraries supplied by mingw. Dave |
From: Earnie B. <ea...@us...> - 2007-01-17 14:38:47
|
Quoting Dave Murphy <win...@nt...>: > > Wouldn't it be better to have separate directories if we want to support > parallel installs of previous/current/candidate? I know it's possible to > have multiple versions of gcc share the same directory but I'm not sure > if the same holds true of binutils and the win32 support libraries > supplied by mingw. > If I install Current and then install Candidate in the same directory as Current I'm expecting to overlay, not a parallel environment. If I install Current in c:/mingw and install Candidate in c:/mingw-rc then I would get the parallelism you refer to. IMO, the user needs to specify the directory regardless of the number of times he runs the installer. The default would become his previous choice. Earnie Boyd -- Please post responsibly: * Use text posts instead of html; many list members just trash mail with html. * Do not use multipart mime to send both text and html versions. * Do not top post replies; post inline with the parts you are responding to. * Trim the post replies; remove irrelevant information from the quoted article. * Original posters: ** Provide small complete examples of the problem. ** Provide the full command that produced errors. ** Provide the versions of the software used. |
From: Greg C. <chi...@co...> - 2007-01-09 15:36:41
|
On 2007-1-9 14:52 UTC, Earnie Boyd wrote: > > With MSYS 1.0.11 it is possible to install the MinGW GCC and friends > into the MSYS /bin directory or vice versa. As a matter of fact I > prefer it that way. I know that Keith has stated that he likes the > keep it separate method installing GCC and friends into /mingw and > installing MSYS into /msys. But if we use the same installer it may be > better to enforce the same directory method. > > Comments? I use both, and I use them separately. That is, I use MinGW gcc with other shells, and in some MSYS sessions I never invoke the compiler. For me, they're conceptually separate, so it makes sense to keep them physically separate; and a shorter path like /MinGW-20050827 is a little easier to use outside of MSYS than, say, /msys/1.0/MinGW-20050827 though that's not a very strong argument. OTOH, suppose I install the toolchains from both mingw.org and cygwin.org, each with its own compiler. (Maybe I use MinGW gcc normally, but want to ensure cygwin compatibility, or just make sure my code works with newlib as well as the msvc rtl.) In that case, a layout like mingw.org-tools/bin/gcc cygwin.org-tools/bin/gcc might be better. (A common directory for tools from mingw.org need not be named '/msys'; but that name is perfect if we want to portray the compiler as one aspect of an MSYS environment.) I guess the main question is whether we want to encourage users to view mingw.org tools as part of a single package. If so, then it makes sense for them to share a directory. But I don't much mind what the default is as long as I can continue to override it. Changing any default could "break" third-party tools like an IDE that expects to find the compiler in /MinGW . I mention that for completeness, so that we can anticipate questions and head them off with documentation--not because a trivial concern like this should prevent changing the default. |
From: Earnie B. <ea...@us...> - 2007-01-09 18:03:21
|
Quoting Greg Chicares <chi...@co...>: > > Changing any default could "break" third-party tools like an > IDE that expects to find the compiler in /MinGW . I mention > that for completeness, so that we can anticipate questions > and head them off with documentation--not because a trivial > concern like this should prevent changing the default. > And MSYS-1.0.11 could easily be installed in c:/mingw or whatever you've called your MinGW installation directory without breaking anything. It'll be easier to use the same installer if the same directory is used. MSYS core doesn't contain a compiler. And for the MSYS developer he would put the MSYS development tools into /msys. In version MSYS-1.0.12 there will be options so that MinGW and MSYS can be installed in the root of the drive, e.g. c:/bin, c:/include, etc and the path translation will not be executed. Earnie |
From: techtonik <tec...@us...> - 2007-01-09 21:26:21
|
On 1/9/07, Earnie Boyd <ea...@us...> wrote: > > With MSYS 1.0.11 it is possible to install the MinGW GCC and friends > into the MSYS /bin directory or vice versa. As a matter of fact I > prefer it that way. I know that Keith has stated that he likes the > keep it separate method installing GCC and friends into /mingw and > installing MSYS into /msys. But if we use the same installer it may be > better to enforce the same directory method. > > Comments? > Make it optional. I.e. provide a checkbox to "install MSYS and MinGW in separate directories". While it is not clicked text fields for choosing installation directories can be disabled or hidden and if it is checked - main directory chooser becomes unavailable for edition. It would desirable to include help why it might be useful to install these that way or vice versa and explain a bit what is MSYS and MinGW for new users, who just downloaded "necessary compiler". BTW, is DTK already merged with MSYS - it seems to be missed from downloads? -- --t. |
From: Earnie B. <ea...@us...> - 2007-01-10 03:41:24
|
Quoting techtonik <tec...@us...>: > > BTW, is DTK already merged with MSYS - it seems to be missed from downloads? > I find it here http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=82721 You have to click the "view older ..." crap. Earnie Boyd -- Please post responsibly: * Use text posts instead of html; many list members just trash mail with html. * Do not use multipart mime to send both text and html versions. * Do not top post replies; post inline with the parts you are responding to. * Trim the post replies; remove irrelevant information from the quoted article. * Original posters: ** Provide small complete examples of the problem. ** Provide the full command that produced errors. ** Provide the versions of the software used. |
From: techtonik <tec...@us...> - 2007-01-10 07:36:32
|
On 1/10/07, Earnie Boyd <ea...@us...> wrote: > > > > BTW, is DTK already merged with MSYS - it seems to be missed from downloads? > > > > I find it here > http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=82721 > > You have to click the "view older ..." crap. > Is it really crap or just limitation of SF file release system that hides the package? There is at least perl required for autotools. Is there any chance to get DTK updated as well? -- --t. |
From: Earnie B. <ea...@us...> - 2007-01-10 14:57:10
|
Quoting techtonik <tec...@us...>: > On 1/10/07, Earnie Boyd <ea...@us...> wrote: >> > >> > BTW, is DTK already merged with MSYS - it seems to be missed from >> downloads? >> > >> >> I find it here >> http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=82721 >> >> You have to click the "view older ..." crap. >> > Is it really crap or just limitation of SF file release system that > hides the package? It is crap because the limitation didn't use to exist and I don't like the new design with the limitation imposed. > There is at least perl required for autotools. Is > there any chance to get DTK updated as well? > What would be really spiffy is if MSYS could use the native version (one of the ultimate goals I have). I have tried to document in the HowTo section of the wiki how to build MSYS dependent applications. Feel free to give it a try. I will not have time to port a newer version of perl. Earnie Boyd -- Please post responsibly: * Use text posts instead of html; many list members just trash mail with html. * Do not use multipart mime to send both text and html versions. * Do not top post replies; post inline with the parts you are responding to. * Trim the post replies; remove irrelevant information from the quoted article. * Original posters: ** Provide small complete examples of the problem. ** Provide the full command that produced errors. ** Provide the versions of the software used. |
From: Earnie B. <ea...@us...> - 2007-01-10 15:11:52
|
Quoting Earnie Boyd <ea...@us...>: > > Dave, I need to understand why you chose to skip the selection sections > of an already chosen Current vs Candidate, etc. I would like to be > able to use the MinGW installer to install a Current version as well as > a Candidate version. > Dave? Earnie |
From: techtonik <tec...@us...> - 2007-01-21 10:39:39
|
On 1/10/07, Earnie Boyd <ea...@us...> wrote: > > > Dave, I need to understand why you chose to skip the selection sections > > of an already chosen Current vs Candidate, etc. I would like to be > > able to use the MinGW installer to install a Current version as well as > > a Candidate version. > Perhaps because they share the same registry keys and second install overwrites the previous one and you will need to update/delete your previously installed package manually. Is this stuff with Current/Candidate/Previous really useful? For a user who need to compile OpenSource projects on Windows system it doesn't seem so. User needs a quick-to-get installer with as little options as possible. Developers could install required MinGW candidates and previous versions by merely unpacking files into correct directories, right? Advanced users could keep it in the same way to download and unpack release they needed given that manual installation instructions are available on the site. If we need to preserve previous behaviour in installer we need to make three different uninstalls for every MinGW variant or one intelligent installer/uninstaller. If there will be one installer then it must be installed into one central location and be able to use uninstall information from all packages regardless of their versions. This can lead to backward compatibility overhead and/or inability to uninstall due to incompatibilities. On the other side even if there are three uninstallers installer need to detect all of them and propose upgrade/install for every version. This becomes even more complicated if you want to add MSYS and DTK into installer. Considering MSYS doesn't have any Current/Candidate options it would only confuse users further (esp. with this all-in-one or separate directory options). I'd propose keep it simple - remove Candidate/Previous from selection completely and concentrate on MSYS/DTK installation. -- --t. |
From: techtonik <tec...@us...> - 2007-01-21 16:37:53
|
One more thing - if you're going to release another version - here is a patch to fix installer's ability for self-improvement. =) On 1/21/07, techtonik <tec...@us...> wrote: > > On 1/10/07, Earnie Boyd <ea...@us...> wrote: > > > > > Dave, I need to understand why you chose to skip the selection > > sections > > > of an already chosen Current vs Candidate, etc. I would like to be > > > able to use the MinGW installer to install a Current version as well > > as > > > a Candidate version. > > > > Perhaps because they share the same registry keys and second install > overwrites the previous one and you will need to update/delete your > previously installed package manually. > > Is this stuff with Current/Candidate/Previous really useful? For a user > who need to compile OpenSource projects on Windows system it doesn't seem > so. User needs a quick-to-get installer with as little options as possible. > Developers could install required MinGW candidates and previous versions by > merely unpacking files into correct directories, right? Advanced users could > keep it in the same way to download and unpack release they needed given > that manual installation instructions are available on the site. > > If we need to preserve previous behaviour in installer we need to make > three different uninstalls for every MinGW variant or one intelligent > installer/uninstaller. If there will be one installer then it must be > installed into one central location and be able to use uninstall information > from all packages regardless of their versions. This can lead to backward > compatibility overhead and/or inability to uninstall due to > incompatibilities. On the other side even if there are three uninstallers > installer need to detect all of them and propose upgrade/install for every > version. > > This becomes even more complicated if you want to add MSYS and DTK into > installer. Considering MSYS doesn't have any Current/Candidate options it > would only confuse users further (esp. with this all-in-one or separate > directory options). > > I'd propose keep it simple - remove Candidate/Previous from selection > completely and concentrate on MSYS/DTK installation. > -- > --t. -- --t. |
From: techtonik <tec...@us...> - 2007-01-21 16:38:26
|
https://sourceforge.net/tracker/index.php?func=detail&aid=1640360&group_id=2435&atid=302435 On 1/21/07, techtonik <tec...@us...> wrote: > > One more thing - if you're going to release another version - here is a > patch to fix installer's ability for self-improvement. =) > > On 1/21/07, techtonik <tec...@us...> wrote: > > > > On 1/10/07, Earnie Boyd <ea...@us... > wrote: > > > > > > > Dave, I need to understand why you chose to skip the selection > > > sections > > > > of an already chosen Current vs Candidate, etc. I would like to be > > > > able to use the MinGW installer to install a Current version as well > > > as > > > > a Candidate version. > > > > > > > Perhaps because they share the same registry keys and second install > > overwrites the previous one and you will need to update/delete your > > previously installed package manually. > > > > Is this stuff with Current/Candidate/Previous really useful? For a user > > who need to compile OpenSource projects on Windows system it doesn't seem > > so. User needs a quick-to-get installer with as little options as possible. > > Developers could install required MinGW candidates and previous versions by > > merely unpacking files into correct directories, right? Advanced users could > > keep it in the same way to download and unpack release they needed given > > that manual installation instructions are available on the site. > > > > If we need to preserve previous behaviour in installer we need to make > > three different uninstalls for every MinGW variant or one intelligent > > installer/uninstaller. If there will be one installer then it must be > > installed into one central location and be able to use uninstall information > > from all packages regardless of their versions. This can lead to backward > > compatibility overhead and/or inability to uninstall due to > > incompatibilities. On the other side even if there are three uninstallers > > installer need to detect all of them and propose upgrade/install for every > > version. > > > > This becomes even more complicated if you want to add MSYS and DTK into > > installer. Considering MSYS doesn't have any Current/Candidate options it > > would only confuse users further (esp. with this all-in-one or separate > > directory options). > > > > I'd propose keep it simple - remove Candidate/Previous from selection > > completely and concentrate on MSYS/DTK installation. > > -- > > --t. > > > > > -- > --t. -- --t. |