Hi, Sorry for the late answer, being that I'm directly concerned with the topic through Installer.app. I'm a bit backloged in several thereads, and the more I procastinate the less I can convince myself to reply... I have the opinions but lack the patiente of writing them. Weird thing, must be a phase :)
On 2005-03-31 14:57:34 +0100 Nicolas Roard <[EMAIL PROTECTED]> wrote: > > Le 31 mars 05, à 13:08, M. Uli Kusterer a écrit : > >> At 15:50 Uhr +0100 30.03.2005, Nicolas Roard wrote: >>> I was just thinking about software distribution... the fans of >>> web-applications have it right: when a bug is corrected, the user see the >>> correction immediately. No "releases" needed. Of course, webapps have >>> other problems (latency, no drag'n drop..). But the idea of fixing >>> something and automatically "push it" to the client is a good one. >> >> You're thinking like a developer. It may help to see this from the point >> of view of the user, too. Some people don't update because they're afraid >> it will introduce new bugs that will hinder their ability to get work done >> even more. "never touch a working system" and "the devil you know / the >> devil you don't". >> >> That's the short version. For the long version, see my blog: >> <http://www.zathras.de/angelweb/x2005-03-13.htm> > > Well, you make good points, yes. Still I'm not speaking of automatic update > without the user's consent > -- it should be volunteer. > I talked with Nicolas on #gnustep the other day about this (after the original mail). It was something that was already lightly referenced before (the ability to deal with source packages and compile them transparently). but Nicolas' mail was to the point. My view on this is that it is a good thing to have, and it doesn't seem very difficult to do *in a basic way*. This means that the idea itself is doable, but ont thing I've learned is that when people want something and it sounds simple I'm usually missing the 90% that they aren't saying and that is the really hard part :). Making a simple bundle with just a file (in the vein of Info.plist) the contains CVS/SVN/TLA checkout/update information, something like GoboLinux recipes and Gentoo ebuilds, but simplified by the general and predictable way GNUstep apps are compiled, doesn't look hard. After compilation one would end up with either a package or an app bundle. Source compiles requires different dependencies, and thus dependencies checking would have to be much more precise. UI issues pop to mind, but this mainly because I suck at it and I'm having trouble with the simple binary Installer. It's doable though, that's what I want to pass, but there is one point that I agree with Uli: it's focused on developers. I tried to explain the concept and the advantages to typical non-computer geeks and I was presented with a "uh?". What I could gather is that people want to find a program on the net by some mean (mail, search, whatever), download it, install it and use it. We could try to hide the behind-the-scenes source compiling, but let's not forget that even so the process would be interesting to developers. >> >>> But what if we had some kind of file containing all the information to >>> grab a cvs ? We could just say to the users "download this file, >>> double-click on it". That will launch Installer.app. >>> Installer.app will then grab the ChangeLog, or just list the available >>> tags, and propose that to the user; >>> the user choose a version (a tag) or the bleeding edge, and click on the >>> "install" button. Installer.app grab the sources and launch the >>> compilation / installation. >> >> ChangeLog isn't that interesting to most users. It's written from the >> developers' point of view. As such, most statements reference names of >> internal classes that users never get to see, or they use inconsistent >> terminology because nobody reviews them for correct terminology. It's a bad >> idea to show this to users, at least as a default. > > My idea was more, "grab a file showing the updates from the cvs". The "real" > ChangeLog isn't the right file for that job -- too technical indeed. > Yes, I sometimes can't understand my own ChangeLog :) >>> It's not very difficult to do in fact (it's just a shell over cvs/svn), >>> but it would provide a much smoother experience for people, and will let >>> us have an easy way of "pushing" new versions. The installer could even >>> check regularly the tags to warn the user for any new releases. >> >> Look at MacPAD for one possible update-check mechanism. And I think going >> through CVS isn't a good idea. Tagging a release is cheap. Actually >> packaging it up and offering it for download means some additional time has >> gone by, it has been tested a little more and it's more likely to be safe. > > Hmm.... you're probably right. Though, I still think we should have a > "CVS/SVN" install available for those who wants. But a same update mechanism > using .tgz is also needed, yes, and probably will be much more used by the > normal user. > I'm looking into the PAD/MacPAD thing. Still haven't found exactly how it works since all I have about MacPAD is some shareware site and another page that doesn't mention licences and offers a .sitx file, that must be some StuffIt archive that I can't decypher. My focus now, and in the future, are binary packages, so this kind of mechanism are interesting. I even talked to Nicolas about a background job that would look inside the apps Info.plist for a key that pointed to some URL and that would allow the user to see if they wanted if there were updates available for the apps installed. Now, I'm biased towards binary packages, but I concur with Nicolas that having the sort of source install/update he mentions would be a nice addition. The only thing in which I'm sceptical is that the mechanism itself should be the prefered way and that there is aneed to push things to the user. Webapps are another beast altogether, since the way that people interact with them and the way they are "installed" is very different. >>> Of course we could continue issue tgz releases anyway, for people that >>> don't want to compile, but nowadays compilation is very fast, so.. >>> >>> What do you think ? >> >> Multiple points of failure, duplication of effort, waste of CPU cycles. >> Remember, your users may have different versions of GCC installed (some >> incompatible, like Apple's), or may have some other problems on their >> machine. Those needn't be big problems, just subtle differences that >> prevent the Makefile from running. You completely eliminate a whole bunch >> of these problems if you just get them a precompiled binary. Also, when a >> packager does this compile once, all his clients don't need to run again, >> saving them CPU cycles that they can use for other things. >> >> There will always be people who want to compile themselves, but those will >> mostly be the more advanced users, so they'll be able to do without a CVS >> installer. I'd rather spend manpower on getting regular installers out the >> door. Of course, I'm fine with having installation scripts etc. No need to >> make life harder for the packagers. But packagers should be savvy enough to >> do a CVS checkout. They probably do that all day anyway. > > Well, I think we definitely wants a binary update mechanism, for the reasons > you describe. But I still think a CVS/SVN installer would also be quite > handy.. it's not because a cvs checkout isn't that difficult that having a > good UI for dealing with it is bad :-) > > But you're right, it's likely that casual users won't want that; this kind of > update mechanism is ok for devs and power users, probably not my grandmother. > Uli makes good points. I, as a developer of sorts, think that the idea is good and that it is indeed a good addition, but in a way the (small) work that has to be put into making a binary package makes the installation provess much more simple and straightforward to the user. As I said to Nicolas yesterday, talking about dependency checking, I'm a big apt fan. I feel really limited without apt, and find it invaluable. But this is so not because it's the more straightforward way to do things, but simply because it makes the *enourmous* dependencies that straight Unix apps have more bearable. The best way to install software, even if I'm an apt fan, is indeed "Hey, let me check this FooBar app my friend talked about.Hey, looks cool, I'll download it and install it". This is something that I haven't be able to do in Unix for years, it reachs the point of being *easier* to just compile the damned thing. This is one point where I thing that GNUstep can make a difference. Once the initial infrastructure is in place apps can be much more self contained. Dependencies checking is great when you need libasn2.5 and libbepepep-nothreads and libroflmao-2.7.0-CVS20050311 in order to run a 20k app. Ideally a GNUstep app would not have many extra deps that are not necessary for the base system itself. I'm reading OSXGNU ideas on simple binary dependency checking to provide a simple way to keep track of what's needed or not, but even this is not such a big issue for most OSX users I've met, maybe because the apps have much less external deps and those deps, if necessary, are installed in sensible ways and with sensible names. BTW, regarding Installer: I have switched to the "popup" UI style (see http://www.gesal.org/gnustep/installer_new.png ). After weighting everything that was said I concluded: o Non-sequential mode makes more sense to a final user- o Tabs made all the tabs look important, as if the user had to see all of them o This way looks better My problem now is what to put in the different views. Initially I thought about putting what was in the tabs (Info, Files, Licence), and that is the way they are now, but it probably makes more sense to follow more closely the initial NeXT desing... Using menu items and nice buttons on the top of the window for this sort of extra info (e.g. "Files", "Licence", "Installation Preferences", with the "Install" button in the first position and apart from the others) and keeping the views to actual different views of the state of the package (main "Info" view, progress, log). This is all very nice, but for this to work I would also need nice buttons :) Feel free to share your views. As far as binary .pkg's go I'm advancing bit by bit but Emacs.pkg already installs with only 2 different files that the OSX package. Final conclusion: I like the idea, can be useful, probably not so much for end users, but still cool. Best Regards, fsmunoz
