From: <14f...@sn...> - 2005-08-24 10:48:08
|
Hi Folks! First of all, before getting flamed, I have to say I really appreciate the work you guys are doing. MinGW is a package that is really valuable to the community, bringing a high-quality compiler (GCC) to the Win32 platform without the hassle. BUT: The packaging is the problem. Being a total newbe, it took me quite a while to figure out what to download. The only thing I was looking for was a simple setup program to it MinGW up on my machine. And frankly, I had a hard time finding it, as it is hidden within the large list of all the packages on the download page. And yes, I read the text on the download webpage, and I have to say there's too much of it, and it doesn't help... What I would expect (and I'm sure I'm not alone there): I go to mingw.org, spend a couple of seconds orientating myself, click on download and look for something saying 'download MinGW installer'. That's all I'm expecting. Instead, I'm slowed down by being forced to read loads of text and figuring out where that installer is (and yep, MinGW.exe is not a good name for an installer, sorry - mingw-setup.exe or even setup-mingw.exe would be a lot better and easier to identify). I recommend you look at java.com; that's the way to go: one huge button saying 'download java' (yeah, I know there are lots of ads, which are confusing, but I'm sure you get the idea). As a conclusion: after I found that MinGW.exe is a web installer that downloads the packages and installs it all automagically, everything was fine - it's really a good solution. Just the way of finding it is a PITA. I suggest you put a large 'DOWNLOAD MinGW distribution here' button on top of the download page, linking to the installer. And I bet your user base will double ;) Hope I didn't step on anyone's toes, but that's my honest opinion. Cheers, Uwe |
From: Earnie B. <ea...@us...> - 2005-08-24 12:33:47
|
On 10:47:56 am 2005-08-24 14f...@sn... wrote: > Hi Folks! > > First of all, before getting flamed, I have to say I really > appreciate the work you guys are doing. MinGW is a package that is > really valuable to the community, bringing a high-quality compiler > (GCC) to the Win32 platform without the hassle. > > BUT: The packaging is the problem. Being a total newbe, it took me > quite a while to figure out what to download. > The only thing I was looking for was a simple setup program to it > MinGW up on my machine. And frankly, I had a hard time finding it, as > it is hidden within the large list of all the packages on the > download page. > No one disagrees with you. I've recently sent the list this statement: <quote> Unless someone is willing to take on maintenance of the MinGW-4 installer I'm going to remove it from the download pages. I don't have time to take care of it. </quote> No one has responded. > And yes, I read the text on the download webpage, and I have to say > there's too much of it, and it doesn't help... > Julien Lecomte is working a FAQ on the MinGWiki. There is good information for the newbie on the wiki and Julien is reformatting the data for easier navagation. Earnie. |
From: <14f...@sn...> - 2005-08-24 13:03:58
|
Hmm... I'm not saying I'm volunteering for it, but I suppose creating an installer could easily be automated with a really simple application that takes a list of tarballs as input and packages them into one single installer package. Isn't that how the current installer is done? I'm sure NSIS would support that (you'd create the installer scripts automatically and run NSIS to package it). If it's not done similar to this right now, what do you think of it? Cheers, Uwe Earnie Boyd earnie-at-users.sourceforge.net |mingw.org| wrote: >On 10:47:56 am 2005-08-24 14f...@sn... wrote: > > >>Hi Folks! >> >>First of all, before getting flamed, I have to say I really >>appreciate the work you guys are doing. MinGW is a package that is >>really valuable to the community, bringing a high-quality compiler >>(GCC) to the Win32 platform without the hassle. >> >>BUT: The packaging is the problem. Being a total newbe, it took me >>quite a while to figure out what to download. >>The only thing I was looking for was a simple setup program to it >>MinGW up on my machine. And frankly, I had a hard time finding it, as >>it is hidden within the large list of all the packages on the >>download page. >> >> >> > >No one disagrees with you. I've recently sent the list this statement: > ><quote> >Unless someone is willing to take on maintenance of the MinGW-4 installer >I'm going to remove it from the download pages. I don't have time to take >care of it. ></quote> > >No one has responded. > > > >>And yes, I read the text on the download webpage, and I have to say >>there's too much of it, and it doesn't help... >> >> >> > >Julien Lecomte is working a FAQ on the MinGWiki. There is good information >for the newbie on the wiki and Julien is reformatting the data for easier >navagation. > >Earnie. > > > >------------------------------------------------------- >SF.Net email is Sponsored by the Better Software Conference & EXPO >September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices >Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA >Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf >_______________________________________________ >MinGW-users mailing list >Min...@li... > >You may change your MinGW Account Options or unsubscribe at: >https://lists.sourceforge.net/lists/listinfo/mingw-users > > |
From: Christophe G. <gr...@cg...> - 2005-08-24 13:18:58
|
On Wed, 24 Aug 2005 14f...@sn... wrote: > Hmm... I'm not saying I'm volunteering for it, but I suppose creating an > installer could easily be automated with a really simple application that > takes a list of tarballs as input and packages them into one single installer > package. Isn't that how the current installer is done? I'm sure NSIS would > support that (you'd create the installer scripts automatically and run NSIS > to package it). Some binarie packages are distributed as tar.gz or tar.bz2 archive but others as exe (ie. pdcurses 2.6.0) It would be easier for people who are using mingw as a cross-compiler (I am in this case) to have all source and binary packages in tar.gz or tar.bz2 with a single installer. It's what is done in the cygwin projet. Hope a similar solution can be used with mingw project. Regards, Christophe --------------------------------------------------------------------- ,-~~-.___. ._. / | ' \ | |"""""""""| -= GRENIER Christophe =- ( ) 0 | | | \_/-, ,----' | | | ==== !_!--v---v--" http://www.cgsecurity.org / \-'~; |""""""""| / __/~| ._-""|| | Email: gr...@cg... =( _____|_|____||________| --------------------------------------------------------------------- |
From: <14f...@sn...> - 2005-08-24 13:29:46
|
I basically agree with you, this is the simplest way to integrate all the packages into a single installer. And, on top of that, you could still create separate installers automatically that just install one package (simply by wrapping a tarball into an EXE installer, using the same system as you do for the complete distribution installer) Cheers, Uwe Christophe GRENIER grenier-at-cgsecurity.org |mingw.org| wrote: > On Wed, 24 Aug 2005 14f...@sn... wrote: > >> Hmm... I'm not saying I'm volunteering for it, but I suppose creating >> an installer could easily be automated with a really simple >> application that takes a list of tarballs as input and packages them >> into one single installer package. Isn't that how the current >> installer is done? I'm sure NSIS would support that (you'd create the >> installer scripts automatically and run NSIS to package it). > > > Some binarie packages are distributed as tar.gz or tar.bz2 archive > but others as exe (ie. pdcurses 2.6.0) > > It would be easier for people who are using mingw as a cross-compiler > (I am in this case) to have all source and binary packages in tar.gz > or tar.bz2 with a single installer. It's what is done in the cygwin > projet. > Hope a similar solution can be used with mingw project. > > Regards, > Christophe > > --------------------------------------------------------------------- > ,-~~-.___. ._. > / | ' \ | |"""""""""| -= GRENIER Christophe =- > ( ) 0 | | | > \_/-, ,----' | | | > ==== !_!--v---v--" http://www.cgsecurity.org > / \-'~; |""""""""| > / __/~| ._-""|| | Email: gr...@cg... > =( _____|_|____||________| > --------------------------------------------------------------------- > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing > & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users |
From: Earnie B. <ea...@us...> - 2005-08-24 18:46:23
|
On 1:29:35 pm 2005-08-24 14f...@sn... wrote: > I basically agree with you, this is the simplest way to integrate all > the packages into a single installer. And, on top of that, you could > still create separate installers automatically that just install one > package (simply by wrapping a tarball into an EXE installer, using > the same system as you do for the complete distribution installer) > As for the .exe versions, they are mainly mine and I can agree to upload tarball versions. > Cheers, > > Uwe > > > Christophe GRENIER grenier-at-cgsecurity.org |mingw.org| wrote: > > > On Wed, 24 Aug 2005 14f...@sn... wrote: > > > >> Hmm... I'm not saying I'm volunteering for it, but I suppose > >> creating an installer could easily be automated with a really > >> simple application that takes a list of tarballs as input and > >> packages them into one single installer package. Isn't that how > >> the current installer is done? I'm sure NSIS would support that > >> (you'd create the installer scripts automatically and run NSIS to > > package it). > > How can I convince you to volunteer? I'm sure NSIS would be able to work as well. Scripts to automate the NSIS source should be able to be produced. Satisfying many users of different desires is complex. One installer may not be enough. The current installer uses INNO Setup to download tarball files and then execute tar and gzip in the chosen install directory. The problem with the current installer is that the library which downloads the files doesn't always work and the library source is closed. Feel free to provide an NSIS version, just be kind enough to maintain it. > > Some binarie packages are distributed as tar.gz or tar.bz2 archive > > but others as exe (ie. pdcurses 2.6.0) > > > > It would be easier for people who are using mingw as a > > cross-compiler (I am in this case) to have all source and binary > > packages in tar.gz or tar.bz2 with a single installer. It's what > > is done in the cygwin projet. > > Hope a similar solution can be used with mingw project. > > The Cygwin installer may be able to be modified to be used, the problem is that we don't control the ftp file system. So the directory tree is flat. It is nice that the Cygwin installer recognizes dependencies and automatically forces the download of the dependency. Earnie |
From: <14f...@sn...> - 2005-08-24 22:34:36
|
Well, the problem here mostly is maintenance. I don't have that much time at my hands as well, but to put your mind at ease I'm currently looking at a solution that is based on Wix (http://sourceforge.net/projects/wix). The idea would be to create an MSI file automatically by having a list of tarballs and some interdependency info about them. From this list, the tool that would have to be written would: a) unzip all tarballs into separate directories b) create an installable feature for each of the tarball's files c) create a Wix installer project file (.wxs) d) run Wix/candle and Wix/light to compile and link the MSI file I think that would be a rather elegant solution that didn't require much maintenance in the future, but the downside is that I think it'd be very hard to implement download on demand with it - so the created installers would simply contain the whole distribution, period. I think this is not so much a problem for the users, since they're used to large downloads anyway nowadays, but it might certainly create more traffic - I don't know though if that's a problem for you guys (and for sourceforge and who else is hosting the installers). What do you think? Cheers, Uwe Earnie Boyd earnie-at-users.sourceforge.net |mingw.org| wrote: >On 1:29:35 pm 2005-08-24 14f...@sn... wrote: > > >>I basically agree with you, this is the simplest way to integrate all >>the packages into a single installer. And, on top of that, you could >>still create separate installers automatically that just install one >>package (simply by wrapping a tarball into an EXE installer, using >>the same system as you do for the complete distribution installer) >> >> >> > >As for the .exe versions, they are mainly mine and I can agree to upload >tarball versions. > > > >>Cheers, >> >>Uwe >> >> >>Christophe GRENIER grenier-at-cgsecurity.org |mingw.org| wrote: >> >> >> >>> On Wed, 24 Aug 2005 14f...@sn... wrote: >>> >>> >>> >>>> Hmm... I'm not saying I'm volunteering for it, but I suppose >>>> creating an installer could easily be automated with a really >>>> simple application that takes a list of tarballs as input and >>>> packages them into one single installer package. Isn't that how >>>> the current installer is done? I'm sure NSIS would support that >>>> (you'd create the installer scripts automatically and run NSIS to >>>> >>>> >>>package it). >>> >>> >>> > >How can I convince you to volunteer? > >I'm sure NSIS would be able to work as well. Scripts to automate the NSIS >source should be able to be produced. Satisfying many users of different >desires is complex. One installer may not be enough. > >The current installer uses INNO Setup to download tarball files and then >execute tar and gzip in the chosen install directory. The problem with the >current installer is that the library which downloads the files doesn't >always work and the library source is closed. > >Feel free to provide an NSIS version, just be kind enough to maintain it. > > > >>> Some binarie packages are distributed as tar.gz or tar.bz2 archive >>> but others as exe (ie. pdcurses 2.6.0) >>> >>> It would be easier for people who are using mingw as a >>> cross-compiler (I am in this case) to have all source and binary >>> packages in tar.gz or tar.bz2 with a single installer. It's what >>> is done in the cygwin projet. >>> Hope a similar solution can be used with mingw project. >>> >>> >>> > >The Cygwin installer may be able to be modified to be used, the problem is >that we don't control the ftp file system. So the directory tree is flat. >It is nice that the Cygwin installer recognizes dependencies and >automatically forces the download of the dependency. > >Earnie > > > >------------------------------------------------------- >SF.Net email is Sponsored by the Better Software Conference & EXPO >September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices >Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA >Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf >_______________________________________________ >MinGW-users mailing list >Min...@li... > >You may change your MinGW Account Options or unsubscribe at: >https://lists.sourceforge.net/lists/listinfo/mingw-users > > |
From: Earnie B. <ea...@us...> - 2005-08-24 22:49:49
|
On 10:34:19 pm 2005-08-24 14f...@sn... wrote: > Well, the problem here mostly is maintenance. I don't have that much > time at my hands as well, but to put your mind at ease I'm currently > looking at a solution that is based on Wix > (http://sourceforge.net/projects/wix). The idea would be to create an > MSI file automatically by having a list of tarballs and some > interdependency info about them. From this list, the tool that would > have to be written would: > > a) unzip all tarballs into separate directories > b) create an installable feature for each of the tarball's files > c) create a Wix installer project file (.wxs) > d) run Wix/candle and Wix/light to compile and link the MSI file > > I think that would be a rather elegant solution that didn't require > much maintenance in the future, but the downside is that I think it'd > be very hard to implement download on demand with it - so the created > installers would simply contain the whole distribution, period. > The maintenance would be for the new files uploaded. Do forget there are ``categories'' of product; Current, Candidate, Previous, Snapshot and Proposed (which I should just merge to Candidate or Snapshot and get rid of). > I think this is not so much a problem for the users, since they're > used to large downloads anyway nowadays, but it might certainly > create more traffic - I don't know though if that's a problem for you > guys (and for sourceforge and who else is hosting the installers). > You should review the complaints of the MinGW-3 Candidate installer from the news item for this project. You'll change your mind quickly that size does matter. > What do you think? > WIX would be good. Since it is XML based I can see how it would deal with the dependencies easily. Earnie |
From: <14f...@sn...> - 2005-08-24 23:48:22
Attachments:
mingw-sizes.xls
|
Glad you like the Wix idea - as to the size, I'm put an excel sheet together that reflects the size of an installer (rough estimation as MSI probably don't compresses so well, but we could still wrap it in RAR or ZIP). What I've included so far sums up to 70 MB, but I'm not sure that this is correct: My problem actually is that I haven't got a clue about what some packages do and whether they should be included (sorry, haven't had the time to dig that deep into MinGW - I practically started today ;). But it would also be an option to split it in two or three chunks, (I quite like the MSYS idea, so maybe we make that as an add-on, although that would complicate matters when creating the installer XMLs). However, if a single large installer is too big for some people, they can still go and install the smaller installers we can create for each package, or even unzip the tarballs themselves. But I'm still convinced that most people wouldn't mind one large installer package (in fact, I'm always happy when I only have to download once - I might have to wait a while, but I just leave it boiling in the background and do something else. But when I install it I don't need to think any more - install and go :) Well, but that's just my opinion ;) Anyways, I'll go for a nap now... (It's 01:45 AM right now *yawn*) Cheers, Uwe Earnie Boyd earnie-at-users.sourceforge.net |mingw.org| wrote: >On 10:34:19 pm 2005-08-24 14f...@sn... wrote: > > >>Well, the problem here mostly is maintenance. I don't have that much >>time at my hands as well, but to put your mind at ease I'm currently >>looking at a solution that is based on Wix >>(http://sourceforge.net/projects/wix). The idea would be to create an >>MSI file automatically by having a list of tarballs and some >>interdependency info about them. From this list, the tool that would >>have to be written would: >> >>a) unzip all tarballs into separate directories >>b) create an installable feature for each of the tarball's files >>c) create a Wix installer project file (.wxs) >>d) run Wix/candle and Wix/light to compile and link the MSI file >> >>I think that would be a rather elegant solution that didn't require >>much maintenance in the future, but the downside is that I think it'd >>be very hard to implement download on demand with it - so the created >>installers would simply contain the whole distribution, period. >> >> >> > >The maintenance would be for the new files uploaded. Do forget there are >``categories'' of product; Current, Candidate, Previous, Snapshot and >Proposed (which I should just merge to Candidate or Snapshot and get rid >of). > > > >>I think this is not so much a problem for the users, since they're >>used to large downloads anyway nowadays, but it might certainly >>create more traffic - I don't know though if that's a problem for you >>guys (and for sourceforge and who else is hosting the installers). >> >> >> > >You should review the complaints of the MinGW-3 Candidate installer from >the news item for this project. You'll change your mind quickly that size >does matter. > > > >>What do you think? >> >> >> > >WIX would be good. Since it is XML based I can see how it would deal with >the dependencies easily. > >Earnie > > > >------------------------------------------------------- >SF.Net email is Sponsored by the Better Software Conference & EXPO >September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices >Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA >Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf >_______________________________________________ >MinGW-users mailing list >Min...@li... > >You may change your MinGW Account Options or unsubscribe at: >https://lists.sourceforge.net/lists/listinfo/mingw-users > > |
From: Leif W <war...@us...> - 2005-08-25 04:26:54
|
> From: <14f...@sn...> > Sent: 2005 August 24 Wednesday 19:47 > > Glad you like the Wix idea - as to the size, I'm put an excel sheet > together that reflects the size of an installer (rough estimation as > MSI > probably don't compresses so well, but we could still wrap it in RAR > or > ZIP). > > What I've included so far sums up to 70 MB, but I'm not sure that this > is correct: I'm always of the camp that smaller is better, even if you use more memory on the client side. I mean, if you haven't got a contemporary amount of memory on a system anyways (512 phys, 512 swap), then either hardware should concern you or you're targeting development on an embedded class system. :p Even so, I think tar.bz2 does well without much slowdown. I've heard people say it's too slow and uses too much memory. But really, I've used it since my Pentium 133 with 32MB with 900kb blocks and Linux kernel, Apache, and MySQL sources without incident or complaint. Nowadays 7-zip does well too. It is LGPL, native to win, ported to Linux. Though it has the capacity to use a lot of memory, I seem to find the best results with text using 7z format, Ultra compression, LZMA method, 12MB dictionary and 96 byte words, requiring 179MB for compression and 14MB for decompression. I have no idea how, but I think it would be nice if an installer could make use of that software. Another option perhaps to run an exe packer (UPX, GPL) on binary files? But I have no idea of other people's experience, if it either (a) corrupts or breaks anything or (b) slows down execution or (c) does better than GNU for size. Both softwares mentioned, as well as NSIS are all on SourceForge. I've made website commentary before but I was not able to get something done. I did have a lot of ideas, one was to auto generate an XML file for the proper web display (up to full-blown web download configurator), possibly to include dependency data and such, and mindful of the possibility that an installer could make use of the central source. Some of the issues with auto generation... * The http://prdownload.sourceforge.net/mingw/ site is flat, SourceForge controlled, only filename, date and size, no meta data. * The File Release System is the only place to impose some sort of category and package hierarchy. Take a look: http://sourceforge.net/project/showfiles.php?group_id=2435 . Additional pertinent info may be architecture (most important if there's a 64-bit port someday alongside the then 32-bit legacy...), file type (source tar.gz or binary executable tar.gz?). Again these options are limited. * File Release System notes (and other descriptive meta data that may be interesting when selecting what to download) are on links from the File Release System page. * SourceForge controls all the pages and thus can change HTML formatting at any time without notice and break everything. So for any build system based on auto-generated XML file, there ought to be a mechanism for notifying breakage to the maintainer of the autogen, and coded such that worst case during breakage of HTML parsing is to use an older cached copy. * The current download page is generated by a script that mixes together info from these two sources. I'm familiar with the parsing, it's not too bad. * I worked a lot on generalizing the parsing. * The eventual goal was to specify just the barest essential "parse config file" and have the parsing code generated from that (upon parse config file change), then parse the pages. The parse config stuff was broken. I had to manually create the parse functions. * I just could not help feeling like it was too bulky and clunky and bloated so I didn't release. * It's in PHP and incomplete. * I wanted to avoid doing all this work for each and every visit to the web page, and without a cron job. * First I wanted the resultant XML file to be stored, updated only if needed. * Second I wanted HTML tables generated only as needed (to avoid parsing XML over and over). * SourceForge controls both sources, and have the last modified time always set to current time, I can't do it that way. * So I figured some sort of hard coded timeout compared to the difference between current time last retrieval of the pages Then I noticed the 4.x installers appeared and I was busy with other things, so I figured there'd no longer have a need for my work anyways, so started to be discouraged. :p And finally took a look at the installer, saw some broken behavior, saw that others saw it, saw Earnie had limited time, and saw that the Inno Setup and NSIS languages were a bit beyond me at this point. So I was confirmed discouraged. Although I find working on code to be extremely enjoyable, I also find I'm extraordinarily slow at the process. It's just a hobby I guess, not a profession, so I don't rack up the experience hours or have the benefit of working on teams or having companies pay for training or conferences. Leif |
From: <14f...@sn...> - 2005-08-25 10:09:05
|
But Leif, all that sounds quite complicated. The only thing I am aiming at is a single installer package (est. size: 70MB), so that it is _very_ easy for newbes to install a working MinGW system without the hassle. All I'd do is create a system that takes an XML and tar.gz/bz2 files and builds a 70MB MSI file out of it, no more, no less. website creation etc. are far beyond the scope, at least for my idea (and the time I've got won't allow for more, also) although you could probably easily do it with XSLT (after all, I'd probably also use it to create the .wxs project file that WiX uses) Can you please guys please tell me what you think of that? would that work (I mean having a rather large 70MB installer)? Cheers, Uwe Leif W warp-9.9-at-usa.net |mingw.org| wrote: > > I'm always of the camp that smaller is better, even if you use more > memory on the client side. I mean, if you haven't got a contemporary > amount of memory on a system anyways (512 phys, 512 swap), then either > hardware should concern you or you're targeting development on an > embedded class system. :p Even so, I think tar.bz2 does well without > much slowdown. I've heard people say it's too slow and uses too much > memory. But really, I've used it since my Pentium 133 with 32MB with > 900kb blocks and Linux kernel, Apache, and MySQL sources without > incident or complaint. Nowadays 7-zip does well too. It is LGPL, > native to win, ported to Linux. Though it has the capacity to use a > lot of memory, I seem to find the best results with text using 7z > format, Ultra compression, LZMA method, 12MB dictionary and 96 byte > words, requiring 179MB for compression and 14MB for decompression. I > have no idea how, but I think it would be nice if an installer could > make use of that software. Another option perhaps to run an exe > packer (UPX, GPL) on binary files? But I have no idea of other > people's experience, if it either (a) corrupts or breaks anything or > (b) slows down execution or (c) does better than GNU for size. Both > softwares mentioned, as well as NSIS are all on SourceForge. > > I've made website commentary before but I was not able to get > something done. I did have a lot of ideas, one was to auto generate > an XML file for the proper web display (up to full-blown web download > configurator), possibly to include dependency data and such, and > mindful of the possibility that an installer could make use of the > central source. Some of the issues with auto generation... > > * The http://prdownload.sourceforge.net/mingw/ site is flat, > SourceForge controlled, only filename, date and size, no meta data. > > * The File Release System is the only place to impose some sort of > category and package hierarchy. Take a look: > http://sourceforge.net/project/showfiles.php?group_id=2435 . > Additional pertinent info may be architecture (most important if > there's a 64-bit port someday alongside the then 32-bit legacy...), > file type (source tar.gz or binary executable tar.gz?). Again these > options are limited. > > * File Release System notes (and other descriptive meta data that may > be interesting when selecting what to download) are on links from the > File Release System page. > > * SourceForge controls all the pages and thus can change HTML > formatting at any time without notice and break everything. So for > any build system based on auto-generated XML file, there ought to be a > mechanism for notifying breakage to the maintainer of the autogen, and > coded such that worst case during breakage of HTML parsing is to use > an older cached copy. > > * The current download page is generated by a script that mixes > together info from these two sources. > > > I'm familiar with the parsing, it's not too bad. > > > * I worked a lot on generalizing the parsing. > > * The eventual goal was to specify just the barest essential "parse > config file" and have the parsing code generated from that (upon parse > config file change), then parse the pages. The parse config stuff was > broken. I had to manually create the parse functions. > > * I just could not help feeling like it was too bulky and clunky and > bloated so I didn't release. > > * It's in PHP and incomplete. > > * I wanted to avoid doing all this work for each and every visit to > the web page, and without a cron job. > > * First I wanted the resultant XML file to be stored, updated only if > needed. > > * Second I wanted HTML tables generated only as needed (to avoid > parsing XML over and over). > > * SourceForge controls both sources, and have the last modified time > always set to current time, I can't do it that way. > > * So I figured some sort of hard coded timeout compared to the > difference between current time last retrieval of the pages > > Then I noticed the 4.x installers appeared and I was busy with other > things, so I figured there'd no longer have a need for my work > anyways, so started to be discouraged. :p And finally took a look at > the installer, saw some broken behavior, saw that others saw it, saw > Earnie had limited time, and saw that the Inno Setup and NSIS > languages were a bit beyond me at this point. So I was confirmed > discouraged. Although I find working on code to be extremely > enjoyable, I also find I'm extraordinarily slow at the process. It's > just a hobby I guess, not a profession, so I don't rack up the > experience hours or have the benefit of working on teams or having > companies pay for training or conferences. > > > Leif > > > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing > & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users |
From: Dave M. <win...@nt...> - 2005-08-25 12:00:01
|
14f...@sn... wrote: > But Leif, all that sounds quite complicated. > > The only thing I am aiming at is a single installer package (est. > size: 70MB), so that it is _very_ easy for newbes to install a working > MinGW system without the hassle. > > All I'd do is create a system that takes an XML and tar.gz/bz2 files > and builds a 70MB MSI file out of it, no more, no less. website > creation etc. are far beyond the scope, at least for my idea (and the > time I've got won't allow for more, also) although you could probably > easily do it with XSLT (after all, I'd probably also use it to create > the .wxs project file that WiX uses) > > Can you please guys please tell me what you think of that? would that > work (I mean having a rather large 70MB installer)? > I've done some work with an NSIS installer for one of my own projects that should work pretty well as a MinGW installer. I did offer to provide this to Earnie some time ago but unfortunately have been rather busier than I expected of late. I've got some free time again this week so I can get back to the skeleton I've been working on and let you see what I have in action within the next few days, if people are still interested. The system I have in place for my own project allows for installation direct from the net or saving of required files to disk for later install. It also has a facility to check for updates to installed packages (including the installer/updater itself) and download as required. Dave |
From: <14f...@sn...> - 2005-08-25 12:13:18
|
Hmm, now that sounds neat as well :) although NSIS is not MSI (which was my reason to not look into it, as it apparently doesn't work as cleanly as NSIS - they question is though if users will notice ;) Uwe Dave Murphy wintermute2k4-at-ntlworld.com |mingw.org| wrote: > I've done some work with an NSIS installer for one of my own projects > that should work pretty well as a MinGW installer. I did offer to > provide this to Earnie some time ago but unfortunately have been > rather busier than I expected of late. I've got some free time again > this week so I can get back to the skeleton I've been working on and > let you see what I have in action within the next few days, if people > are still interested. > > The system I have in place for my own project allows for installation > direct from the net or saving of required files to disk for later > install. It also has a facility to check for updates to installed > packages (including the installer/updater itself) and download as > required. > > Dave > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing > & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users |
From: <14f...@sn...> - 2005-08-25 12:34:27
|
Now that comes from sending email without reading it again: Of course I meant that apparently NSIS is not working as cleanly as MSI, but you guys probably figured that out anyways ;) Cheers, Uwe 14ft9wv02-at-sneakemail.com |mingw.org| wrote: > Hmm, now that sounds neat as well :) although NSIS is not MSI (which > was my reason to not look into it, as it apparently doesn't work as > cleanly as NSIS - they question is though if users will notice ;) > > Uwe > |
From: Dave M. <win...@nt...> - 2005-08-26 09:32:25
|
14f...@sn... wrote: > Hmm, now that sounds neat as well :) although NSIS is not MSI (which > was my reason to not look into it, as it apparently doesn't work as > cleanly as NSIS - they question is though if users will notice ;) > Sent this earlier but got moderated due to large attachments. Hosted them on webspace now. the precompiled installer/updater http://devkitpro.org/files/MinGWUpdater-1.0.0.rar the nsis script and required data files http://devkitpro.org/files/installer_src.rar Well, personally I think the MSI approach would add another burden to the package maintainers. Here's my first cut at an NSIS based installer. On first install this app will allow the user to pick a sourceforge mirror site and request download only or download and install. The second dialogue gives a choice of Previous, Current and Candidate packages moving on to pick individual components, install directory and Start Menu. If the required tarballs aren't found in the same directory as the installer/updater they will be downloaded from the chosen mirror then extracted to the chosen install directory. Subsequent runs of the application enter update mode where the user can choose to install packages not installed on the first run or update installed packages with newer versions. The installer/updater is copied to the install directory and an "update" shortcut inserted in the start menu group. This is all acheived through an ini file which gives the name of the current tarball for each component of each install type. The first section is a version for the installer itself and allows for the app to update itself. The trailing |0 on each tarball would be the installed size to allow the installer to calculate disk space requirements. The ini file itself is both embedded in the installer ( but an ini of the same name in the same directory overrides this to allow for an installer package which does not require net access) and would be hosted on the mingw website. A package maintainer would merely have to upload a new tarball and edit the appropriate line in the hosted ini file. For what it's worth the plugin used to extract the tarballs can also handle bzip2 and lzma compressed tarballs, both of which would reduce the size of the downloads. [mingwupdate] Build=1 URL=http://www.mingw.org Filename=mingwupdate-1.0.0.exe [current] runtime=mingw-runtime-3.7.tar.gz|0 w32api=w32api-3.2.tar.gz|0 binutils=binutils-2.15.91-20040904-1.tar.gz|0 core=gcc-core-3.4.2-20040916-1.tar.gz|0 gpp=gcc-g++-3.4.2-20040916-1.tar.gz|0 g77=gcc-g77-3.4.2-20040916-1.tar.gz|0 ada=gcc-ada-3.4.2-20040916-1.tar.gz|0 java=gcc-java-3.4.2-20040916-1.tar.gz|0 objc=gcc-objc-3.4.2-20040916-1.tar.gz|0 make=mingw32-make-3.80.0-3.tar.gz|0 [previous] runtime=mingw-runtime-3.6.tar.gz|0 w32api=w32api-3.1.tar.gz|0 binutils=binutils-2.13.90-20030111-1.tar.gz|0 core=gcc-core-3.3.1-20030804-1.tar.gz|0 gpp=gcc-g++-3.3.1-20030804-1.tar.gz|0 g77=gcc-g77-3.3.1-20030804-1.tar.gz|0 ada=gcc-ada-3.3.1-20030804-1.tar.gz|0 java=gcc-java-3.3.1-20030804-1.tar.gz|0 objc=gcc-objc-3.3.1-20030804-1.tar.gz|0 [candidate] runtime=mingw-runtime-3.7.tar.gz|0 w32api=w32api-3.2.tar.gz|0 binutils=binutils-2.15.94-20050118-1.tar.gz|0 core=gcc-core-3.4.4-20050522-1.tar.gz|0 gpp=gcc-g++-3.4.4-20050522-1.tar.gz|0 g77=gcc-g77-3.4.4-20050522-1.tar.gz|0 ada=gcc-ada-3.4.4-20050522-1.tar.gz|0 java=gcc-java-3.4.4-20050522-1.tar.gz|0 objc=gcc-objc-3.4.4-20050522-1.tar.gz|0 Obviously there's still a little tidying to be done ( license screen for one and detection of Windows version for purposes of path inserion) but I think this is pretty close to what's needed. Constructive criticism appreciated. Dave |
From: <14f...@sn...> - 2005-08-26 10:49:40
|
Yep, that's neat! One thing: how do you handle dependencies? I couldn't see that just the core package would be installed, for instance, and some packages don't show up at all in the install dialog (I assume they're silently installed, are they? like win32 API, or gcc-core, for instance) But other than that, I find it quite neat (and yep, that's what I had expected when I surfed onto the download page - a big fat link to this installer). Oh, and one more thing about categories ('previous', 'current', 'candiate'): I'd make it more obvious to the new user what that is. Or maybe even hide it in an advanced dialog, or at least explaining that new users should use 'current'. Something like that. Cheers, Uwe Dave Murphy wintermute2k4-at-ntlworld.com |mingw.org| wrote: > 14f...@sn... wrote: > >> Hmm, now that sounds neat as well :) although NSIS is not MSI (which >> was my reason to not look into it, as it apparently doesn't work as >> cleanly as NSIS - they question is though if users will notice ;) >> > > Sent this earlier but got moderated due to large attachments. Hosted > them on webspace now. > > the precompiled installer/updater > > http://devkitpro.org/files/MinGWUpdater-1.0.0.rar > > the nsis script and required data files > > http://devkitpro.org/files/installer_src.rar > > Well, personally I think the MSI approach would add another burden to > the package maintainers. > > > Here's my first cut at an NSIS based installer. > > On first install this app will allow the user to pick a sourceforge > mirror site and request download only or download and install. The > second dialogue gives a choice of Previous, Current and Candidate > packages moving on to pick individual components, install directory and > Start Menu. If the required tarballs aren't found in the same directory > as the installer/updater they will be downloaded from the chosen mirror > then extracted to the chosen install directory. Subsequent runs of the > application enter update mode where the user can choose to install > packages not installed on the first run or update installed packages > with newer versions. The installer/updater is copied to the install > directory and an "update" shortcut inserted in the start menu group. > > This is all acheived through an ini file which gives the name of the > current tarball for each component of each install type. The first > section is a version for the installer itself and allows for the app to > update itself. The trailing |0 on each tarball would be the installed > size to allow the installer to calculate disk space requirements. The > ini file itself is both embedded in the installer ( but an ini of the > same name in the same directory overrides this to allow for an installer > package which does not require net access) and would be hosted on the > mingw website. A package maintainer would merely have to upload a new > tarball and edit the appropriate line in the hosted ini file. > > For what it's worth the plugin used to extract the tarballs can also > handle bzip2 and lzma compressed tarballs, both of which would reduce > the size of the downloads. > > [mingwupdate] > Build=1 > URL=http://www.mingw.org > Filename=mingwupdate-1.0.0.exe > > [current] > runtime=mingw-runtime-3.7.tar.gz|0 > w32api=w32api-3.2.tar.gz|0 > binutils=binutils-2.15.91-20040904-1.tar.gz|0 > core=gcc-core-3.4.2-20040916-1.tar.gz|0 > gpp=gcc-g++-3.4.2-20040916-1.tar.gz|0 > g77=gcc-g77-3.4.2-20040916-1.tar.gz|0 > ada=gcc-ada-3.4.2-20040916-1.tar.gz|0 > java=gcc-java-3.4.2-20040916-1.tar.gz|0 > objc=gcc-objc-3.4.2-20040916-1.tar.gz|0 > make=mingw32-make-3.80.0-3.tar.gz|0 > > [previous] > runtime=mingw-runtime-3.6.tar.gz|0 > w32api=w32api-3.1.tar.gz|0 > binutils=binutils-2.13.90-20030111-1.tar.gz|0 > core=gcc-core-3.3.1-20030804-1.tar.gz|0 > gpp=gcc-g++-3.3.1-20030804-1.tar.gz|0 > g77=gcc-g77-3.3.1-20030804-1.tar.gz|0 > ada=gcc-ada-3.3.1-20030804-1.tar.gz|0 > java=gcc-java-3.3.1-20030804-1.tar.gz|0 > objc=gcc-objc-3.3.1-20030804-1.tar.gz|0 > > [candidate] > runtime=mingw-runtime-3.7.tar.gz|0 > w32api=w32api-3.2.tar.gz|0 > binutils=binutils-2.15.94-20050118-1.tar.gz|0 > core=gcc-core-3.4.4-20050522-1.tar.gz|0 > gpp=gcc-g++-3.4.4-20050522-1.tar.gz|0 > g77=gcc-g77-3.4.4-20050522-1.tar.gz|0 > ada=gcc-ada-3.4.4-20050522-1.tar.gz|0 > java=gcc-java-3.4.4-20050522-1.tar.gz|0 > objc=gcc-objc-3.4.4-20050522-1.tar.gz|0 > > > Obviously there's still a little tidying to be done ( license screen for > one and detection of Windows version for purposes of path inserion) but > I think this is pretty close to what's needed. > > Constructive criticism appreciated. > > Dave > > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing > & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users |
From: Dave M. <win...@nt...> - 2005-08-26 14:53:04
|
14f...@sn... wrote: > Yep, that's neat! > > One thing: how do you handle dependencies? I couldn't see that just > the core package would be installed, for instance, and some packages > don't show up at all in the install dialog (I assume they're silently > installed, are they? like win32 API, or gcc-core, for instance) win32api, runtime, binutils and the core compiler all come under base tools on the initial installation. On later updates they'll be shown individually - you can simulate an update by editing the installed.ini file in the install directory and changing the name of some of the installed tarballs then click the update shortcut in the start menu ( or run MinGWUpdater in the install directory. > > Oh, and one more thing about categories ('previous', 'current', > 'candiate'): I'd make it more obvious to the new user what that is. Or > maybe even hide it in an advanced dialog, or at least explaining that > new users should use 'current'. Something like that. > Sure, there's enough space in the dialogue for a brief explanation of those options. Dave |
From: Leif W <war...@us...> - 2005-08-26 15:18:29
|
> From: "Dave Murphy" <win...@nt...> > Sent: 2005 August 26 Friday 05:32 > Here's my first cut at an NSIS based installer. Thanks for posting! Taking a look, if I understand anything. :p > On first install this app will allow the user to pick a sourceforge > mirror site and request download only or download and install. The Is it possible to code a unique random algorithm in NSIS? With mirrors a b c d, pick b at random, then pick from a c d at random, test if the file exists on the server with a HEAD request, and get it if it exists, or else pick another server, until run out, and then start again with all servers. The point of mirrors is not to overload any single mirror by downloading everything from it. Then maybe a mirror is slow or has some problem, it might be handy to add/remove sources (mirrors). > second dialogue gives a choice of Previous, Current and Candidate Again, this sometimes does not work. It may be the case that the "Current" version does not exist, it's only in "Candidate". But if you choose "Candidate", you don't get what's in "Current". Picking "most recent" should look for the most recent version in any release category. > then extracted to the chosen install directory. Subsequent runs of the > application enter update mode where the user can choose to install > packages not installed on the first run or update installed packages > with newer versions. The installer/updater is copied to the install Ahh, this might suffice, but might be confusing. We'd just have to see what happens. > mingw website. A package maintainer would merely have to upload a new > tarball and edit the appropriate line in the hosted ini file. That might not be too bad. Maybe even scriptable to pull the data, if people stuck the data in a pullable location. > For what it's worth the plugin used to extract the tarballs can also > handle bzip2 and lzma compressed tarballs, both of which would reduce > the size of the downloads. Sweet. As I noticed ealier in the week. > Obviously there's still a little tidying to be done ( license screen > for > one and detection of Windows version for purposes of path inserion) > but > I think this is pretty close to what's needed. Hmm, there's the lacking versioning, dendency or conflict stuff in the .ini. Can NSIS do numerical comparisons and such? I imagine so, but don't know how it'd be specified. I'll read up on NSIS today. Leif |
From: Dave M. <win...@nt...> - 2005-08-27 07:10:23
|
Leif W wrote: > > Is it possible to code a unique random algorithm in NSIS? With > mirrors a b c d, pick b at random, then pick from a c d at random, > test if the file exists on the server with a HEAD request, and get it > if it exists, or else pick another server, until run out, and then > start again with all servers. The point of mirrors is not to overload > any single mirror by downloading everything from it. Then maybe a > mirror is slow or has some problem, it might be handy to add/remove > sources (mirrors). The sourceforge mirror sites are given by region. I was under the impression users should pick a mirror by closest geographical location which would give best download speed and thus loading servers for less time. It seems to me that if the point of the mirrors was load balancing then the user wouldn't be given a choice It's certainly possible to allocate mirrors for download in a round robin or random fashion and even allow for input of a set of mirrors. I do think that user management of sources is getting into territory likely to confuse the end users of an "easy install system" for windows. > Again, this sometimes does not work. It may be the case that the > "Current" version does not exist, it's only in "Candidate". But if > you choose "Candidate", you don't get what's in "Current". Picking > "most recent" should look for the most recent version in any release > category. > As I understand these terms, "previous" is the last stable version, "current" is the present stable version, "candidate" is the most recent (and bleeding edge). > Ahh, this might suffice, but might be confusing. We'd just have to > see what happens. > Confusing in what way? Initial install and subsequent update seems perfectly straightforward to me. Most of the groundwork for this installer was done on another project, the end users there have had no problems. > > Hmm, there's the lacking versioning, dendency or conflict stuff in the > .ini. Can NSIS do numerical comparisons and such? I imagine so, but > don't know how it'd be specified. This could be implemented if necessary but again, I feel it's getting away from an "easy installer" and moving towards a package manager like debian's apt. My experience with windows end users of gnu tools would seem to indicate that the majority just want to click an installer and have a complete toolchain they can program with - thus the popularity of Dev-Cpp which includes an editor and protects people from the intricacies of makefiles. Ultimately I think we have to balance ease of use from both sides of the coin and my personal choice would be to go with a system that causes least disruption to the people kindly donating their time to provide the binary packages. Dave |
From: Leif W <war...@us...> - 2005-08-28 08:57:42
|
> From: "Dave Murphy" <win...@nt...> > Sent: 2005 August 27 Saturday 03:10 > > Leif W wrote: > >> start again with all servers. The point of mirrors is not to >> overload any single mirror by downloading everything from it. Then >> maybe a > > The sourceforge mirror sites are given by region. I was under the > impression users should pick a mirror by closest geographical location > which would give best download speed and thus loading servers for less > time. It seems to me that if the point of the mirrors was load > balancing then the user wouldn't be given a choice I am going by the prdownloads site. It does not attempt to detect my region and list only close servers, though it could be done with GeoIP from MaxMind. But anyways, geographic region has little to do with internet speed. There are so many other variables that will make a machine next door run slower than one in eastern Europe or Japan at any given moment. Could be network outages even. Could even take 15 hops to go next door but only 5 to go around the world. Network topology is more signifiganct that geography. Sometimes servers don't have the file, though it's been released for months. Odd things happen. > do think that user management of sources is getting into territory > likely to confuse the end users of an "easy install system" for > windows. Yeah, again, why I'd just consider a distinction between "Basic" and "Advanced" mode dialogs. :p Or at the least, check for a sources file and use it if available , otherwise fall back to the hard coded one. >> Again, this sometimes does not work. It may be the case that the >> "Current" version does not exist, it's only in "Candidate". But if >> you choose "Candidate", you don't get what's in "Current". Picking >> "most recent" should look for the most recent version in any release >> category. > > As I understand these terms, "previous" is the last stable version, > "current" is the present stable version, "candidate" is the most > recent (and bleeding edge). It'd be nice if it was always like that but there are cases when it's not. New releases, new versions of software which have been Candidates for a long time and at their last Candidate release, but not bumped to Current. To get a completely updated toolset I need to pick from each category. >> Ahh, this might suffice, but might be confusing. We'd just have to >> see what happens. >> > Confusing in what way? Initial install and subsequent update seems A new user reads that Candidate will give them the most recent thing, but they get only gcc and binutils, but if they need MSYS and that, they've got to go get current, then there's no version checking, so the Candidate stuff, is it there, is it blown away, are the versions compared and not install the older? >> Hmm, there's the lacking versioning, dendency or conflict stuff in >> the .ini. Can NSIS do numerical comparisons and such? I imagine so, >> but don't know how it'd be specified. > > This could be implemented if necessary but again, I feel it's getting > away from an "easy installer" and moving towards a package manager > like Easy install is one thing, and easy management is another, both equally useful. It's very easy to install a tar ball. Managing what's installed, what might be conflicting, that can become a bother. > debian's apt. My experience with windows end users of gnu tools would > seem to indicate that the majority just want to click an installer and > have a complete toolchain they can program with - thus the popularity > of Which is fine. But then in 6 months or a year they might want to update. Maybe update more frequently if something they need comes out. Without some kind of management tool a user might be back at square one having to figure out installs, which they already maybe wouldn't have learned, as they've become dependent on the installer as a crutch to hide the details. :p > Ultimately I think we have to balance ease of use from both sides of > the coin and my personal choice would be to go with a system that > causes least disruption to the people kindly donating their time to > provide the binary packages. I don't want to create any extra work for anyone. But I do not think a few lines describing version, dependency or conflict data in release notes (which must be given anyways) is too much to ask of a release manager. But if it is, I'd at least maintain that info elsewhere. In any case, ok, it's at least a step in the right direction to have a nice downloader and installer sans maintenance. Leif |
From: Leif W <war...@us...> - 2005-08-25 15:20:09
|
> From: <14f...@sn...> > Sent: 2005 August 25 Thursday 06:08 > > The only thing I am aiming at is a single installer package (est. > size: 70MB), so that it is _very_ easy for newbes to install a working > MinGW system without the hassle. The idea is to have a single download, and from that the ability to select specific components. That is a very good idea. But let's make a distinction now between a monolithic snapshot masquerading as installer, and a network installer that downloads only what is chosen. With the monolithic installer, each time any small package is updated, an entirely new installer is made. People will be linking to the old installers, getting the new installer instead of the one updated package, and so on. Once a file is uploaded to SourceForge it can't easily be removed. It's a waste of resources, IMO. Both disc and network transfer, and makes everything quite confusing. Each package is it's own entity, living at it's own speed (release cycles). With a network installer, you download only what is desired. The components are treated independently, so you're not archiving all the other unchanged packages for a single (or a few) package update(s). The problem is the situation where people want to reinstall later, install on multiple machines from a local copy, or need to download on one computer, copy to removeable media, and install on another computer. So a network installer must also cater to that. Again, it's wasteful to force downloading everything if it's known to not be needed, but it needs to be totally possible to choose to download everything and install offline. Apart from my misgivings of the Cygwin installer (that it forgets everything I selected on each run), I did very much like that it let me do precisely what I'm talking about. I could download as much or as little as I wanted, and install from the local downloaded copy as many time as I wanted, move the directory around and carry on. Now, with a network installer, you have a situation where you might need to build a new installer for every new package or every few new packages. Again, I think that would kind of suck, but it's much better to build a 500kb installer than a 70MB (and growing rapidly? was 50MB at beginning of year, or poor MSI compression?) archive each time. Still, it doesn't sit well with me as the best solution. For that, I turn to the CVS idea for inspiration, specifically tagging. Note, CVS is suited mainly for text data such as souce code, and not binary files. This would again lead to multiple copies of everything, wasting resources. Nothing to do with CVS proper, it's just the concept of tagging. Instead of "tagging" a release by monolithic archive, or even by network installer version, further generalize the concept of release and separate it from the installer entirely. A release could then be defined as a specific collection of files at specific versions. The data could be stored somewhere, in a database and exported to XML for instance. Then in the installer, you start by retrieving that file. You must at some point be online to retrieve anything, agreed? So you retrieve the installer, run the installer, it grabs it's config file (or updates an old one if desired). Then maybe choose Default (for beginners) or Advanced modes. Default it chooses the most recent "MinGW" and "MSYS" version, Advanced you choose the abstract MinGW or MSYS version tag. Then you proceed to select which generic names you want, Default mode hides individual package files, Advanced shows all file info. > All I'd do is create a system that takes an XML and tar.gz/bz2 files > and Well, whatever compression suits people. NSIS has a plugin to support creation and extraction of 7-zip files using LZMA method as I previously described. > builds a 70MB MSI file out of it, no more, no less. website creation > etc. are far beyond the scope, at least for my idea (and the time I've The point of mentioning the website page was two fold and not to be construed as implying you must make the web page. The first and foremost point is a centralized, automatically generated, hands free, "only bug me if you're broken" way to generate the XML to be used to feed any and all installation dialogs, be they web or network installer. That way, people merrily update packages and don't have to fret too much over updating installers or websites and such. The second point was to illustrate that such a file might have multiple purposes. It was perhaps a bit off topic, sorry, but was nonetheless part of a comprehensive overview of the task of getting MinGW (and MSYS) to users. > Can you please guys please tell me what you think of that? would that > work (I mean having a rather large 70MB installer)? Many have said no to that as /only/ option. For my vote I'd say no as any option. Yeah, I did use the monolithic installer for MinGW 3.x and yes it was very easy. But, after thinking of all the implications, it's not looking very attractive anymore. The purpose of release versions is to communicate a specific set of package versions. That information can be reduced from a monolithic archive down to the simplest, barest essentials of a text description (be it in a database or XML file). The Source Forge factors can't be ignored if they're being used as the primary storage and distribution system, which does greatly complicate matters, but not grievously so I hope. Nonetheless it does take the combination of time, skill and inspiration. I've got two out of three, lacking skill apparently. :p Leif |
From: Daniel K. O. <dan...@ya...> - 2005-08-26 02:21:56
|
14f...@sn... wrote: > The only thing I am aiming at is a single installer package (est. > size: 70MB), so that it is _very_ easy for newbes to install a working > MinGW system without the hassle. I don't think this is too realistic. From my point of view, newbies have no idea how to really use a compiler directly. I see them always comming to MinGW's download page (I know because I send a lot of them there), and if they are able to download it, usually have no idea on how to use it. Then they either get an IDE that bundles MinGW (like Dev-C++) or just give up because "it's too much trouble". Instead of making it _very_ easy for newbies, I think it's more important to make it pratical to use it (the installer). 70 MB isn't pratical. 50 MB isn't pratical. A <1 MB installer able to check the "installed" tools and download the proper updates/new packages is pratical. Here's how I would (and maybe will) do it: a Python script that "parses" <mingwdir>\manifest\*.mft files (the GnuWin32 guys use these, right?), then use a webspider to parse the list at http://prdownloads.sourceforge.net/mingw (even though it isn't valid HTML), then displays the latest version of each package. A "configuration/meta-data file" could be also downloaded from MinGW's website - maybe directly from the wiki - to tell the dependencies, which packages to ignore, etc - and then download them and extract them to the proper directory. Hypothetically: ---- $ mingwsetup update Checking for newer script version... No. Getting udpated packages list from http://www.mingw.org/MinGWiki/index.php/packagesinfo 7 package(s) in your system seem to be outdated. Done. $ mingwsetup upgrade all Upgrading 7 package(s): gcc-core-3.3.3-20040217-1 --> gcc-core-3.4.4-20050522-1 (OK) gcc-g++-3.3.3-20040217-1 --> gcc-g++-3.4.4-20050522-1 (OK) mingw-runtime-3.7 --> mingw-runtime-3.8 (OK) ... Upgraded 7 package(s). Done. ---- Some "special targets" for an "install/upgrade/uninstall" command could be "c++", "java", "c", "all", etc, so this: $ mingwsetup install java would install gcj and all the needed stuffs. I'm suggesting Python because I know a Python programmer that have experience in parsing bad HTML and structured text, and can give me a hand at this. This system could then be useful to both experienced users and newbies that *at least know how to use the command-line*. No extra burden for the current maintainers; the only maintenance would be to keep the script compatible with any SF update, and keep the meta-data file updated with the releases. I believe it could look something like: ---- [packages] gcc-core-3.4.4-20050522-1 gcc-g++-3.4.4-20050522-1 gcc-core-3.4.4-20050522-1 mingw-runtime-3.8 ... [ignore] ChangeLog.mingw *-src.tar.gz auto-import-sample.zip *-release_notes.txt ... ---- --- Daniel K. O. _______________________________________________________ Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora! http://br.acesso.yahoo.com/ |
From: Leif W <war...@us...> - 2005-08-26 03:15:08
|
> From: "Daniel K. O." <dan...@ya...> > Sent: 2005 August 25 Thursday 22:21 > > pratical. 50 MB isn't pratical. A <1 MB installer able to check the > "installed" tools and download the proper updates/new packages is > pratical. > > Here's how I would (and maybe will) do it: a Python script that > "parses" Well, it requires installing Python, which is a few MB? Or does Python allow compilation to a binary? > http://prdownloads.sourceforge.net/mingw (even though it isn't valid > HTML), then displays the latest version of each package. A > I'm suggesting Python because I know a Python programmer that have > experience in parsing bad HTML and structured text, and can give me a > hand at this. Well, I looked at the TCL code used to generate the releases table included in the download.shtml page. I have some parsing functions in PHP, but it's not very pretty at the moment. However, here's the comments I used which basically distils the process to the bare essentials. /* * Download from prdownloads page: * * back.gif __ * .gif,>,>,fName,< | * label-size,>,fSize,< | * label-date,>,fDate,< | * -- */ With my PHP algorithm, I load the entire to one string variable, to avoid potential problems with doing things line by line in the cases where requisite date may span many lines, or all be in one line. I use successive strpos calls to find the next instance of a string, and remember that offset, and call my next strpos from that offset. Try to do it by eye first to understand. It's really not so bad. But the technique is vulnerable to small changes which are out of our control and may occur at any time, but usually very rarely occur. Instead of rewriting functions by hand, I had the idea to somehow capture the essentials visually depicted above and verbally described below. Then upon error, I just visually inspect the file, see how the format changed, update the essential info (stepping or seeking), and have the new parse function auto generated. I kind of made some progress, but not too good, ugly and incomplete, it's just slightly beyond me. What would be really bright is to detect what changed and update the essential seek/step config automatically. :p That's further still beyond me. Look for the "back.gif" string. The first one is just before the junk we want. Assume complete set is zero. Now we loop, either testing by file length or set completion. File length is what I used, followed by set completion check after loop. Look for .gif, then >, then >, remember position. Look for <. file name is in between. May need to trim whitespace. Check that it's not an empty string. maybe other content checks. Break loop on error else increment set flag. Look for label-size, then >, remember position. Look for <. file size is in between. May need to trim whitespace. Check that it's (a string that can be converted to) a number, not size zero. Break loop on error else increment set flag Look for label-date, then >, remember position. Look for <. file date is in between. May need to trim whitespace. Check that it's not an empty string. maybe other content checks. Break loop on error else increment set flag Modulus set completion flag by the number of data pieces per set, to reset to zero. Assume complete set, store it in a data structure and continue loop, else error. Outside loop, check group, to make sure it didn't error somewhere. If you haven't got a complete set (flag zero), you bailed early, so your collected data is likely bogus. Otherwise function may be successful. It depends on your "other content checks" above. I skipped further tests just to get other stuff working, and was visually verifying good data parsing. Leif |
From: Daniel K. O. <dan...@ya...> - 2005-08-26 04:56:16
|
Leif W wrote: > Well, it requires installing Python, which is a few MB? Or does > Python allow compilation to a binary? With py2exe it would require at most 1 MB (but I believe it would be less than that, with just a command-line interface). My friend estimated that what I proposed would need something from 100 to 500 lines of code. And you need Python anyways if you want a more complete development environment, almost as much as you need Perl; so it can be provided in 2 ways, binary and script. But he then suggested to use Smart (http://smartpm.org/) so we only need to write a Channel that retrieves data from the prdownloads page. We already have some experience parsing invalid HTML pages with BeautifulSoup, so this will be the easier part. Smart currently doesn't compile directly on Windows, but I think I can hack it a bit and make it work. --- Daniel K. O. _______________________________________________________ Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora! http://br.acesso.yahoo.com/ |
From: Julien L. <lec...@fr...> - 2005-08-26 08:36:25
|
=20 > -----Original Message----- > From: min...@li...=20 > [mailto:min...@li...] On Behalf Of=20 > Daniel K. O. > Sent: vendredi 26 ao=FBt 2005 06:56 > To: min...@li... > Subject: Re: [Mingw-users] Constructive Website Criticism >=20 > Leif W wrote: >=20 > > Well, it requires installing Python, which is a few MB? Or does=20 > > Python allow compilation to a binary? >=20 > With py2exe it would require at most 1 MB (but I believe it=20 > would be less than that, with just a command-line interface).=20 > My friend estimated that what I proposed would need something=20 > from 100 to 500 lines of code. > And you need Python anyways if you want a more complete=20 > development environment, almost as much as you need Perl; so=20 > it can be provided in 2 ways, binary and script. >=20 > But he then suggested to use Smart (http://smartpm.org/) so=20 > we only need to write a Channel that retrieves data from the=20 > prdownloads page. We already have some experience parsing=20 > invalid HTML pages with BeautifulSoup, so this will be the=20 > easier part. Smart currently doesn't compile directly on=20 > Windows, but I think I can hack it a bit and make it work. >=20 >=20 > --- > Daniel K. O. >=20 When parsing http://prdownloads.sourceforge.net/mingw; how can you tell which version is current, candidate, etc ? Won't that have to be hard-scripted ? Julien |