On Thu, 10 Mar 2005 09:49, Christian Lohmaier wrote: > On Thu, Mar 10, 2005 at 08:43:26AM +1000, Alex Fisher wrote: > > On Thu, 10 Mar 2005 00:20, Alex Thurgood wrote: > > > Le mardi 08 mars 2005 � 22:19 +0100, Christian Lohmaier a �crit : > > > > > - why can't I choose graphically where to install OpenOffice.org > > > > > like I used to be able to do ? > > > > > > > > Because now you can install OOo like every other package. If you want > > > > a graphical interface, use a GUI for RPM. > > > > None of which are adequate for relocating packages, nor can most be used > > for executing "rpm -i --nodeps <package>". > > The only requirements of the OOo packages is /bin/sh (and other OOo > packages) there will be no reason to force the install using nodeps. > > Although the GUIs don't have a switch to use nodeps, they will usually > ask something like "Dependencies for package not met. Continue anyway?"
None that I've used so far do that. Kpackage and RPMDrake will simply say "The following packages cannot be installed..." (sometimes the message is "The following packages cannot be selected" which is even more annoying), and then when the OK button is clicked the program exits.... > > > the old KDE kpackage utility was good > > there, but it seems to have been dropped in favour of gurpmi and > > Mandrake's rpmdrake, both of which are merely front ends to urpmi. > > (Kpackage was a front end to rpm.) Neither of these graphical front ends > > allows one to set any of the options such as --nodeps or a different > > install location. > > So? Not using the default locations is something that the casual user > (the clueless ones) won't do. > > If you don't install your other software into custom locations, why > would you make an exception for OOo? Which is precisely what the current RPMs do... I have normally installed my programs into </usr/local/>, but with the O.o packages (and the old install script did the same), everything gets put in </opt/>. so in fact OO.o is the exception, not the rule, and it would be nice to be able to place it into </usr/local>... But I can't from a GIU. > > > > I'm sorry, but I disagree. Your anwser is like saying : here hapless > > > child, I gave you a cake with a cherry and cream on it in Version > > > 1.x.x, and now for Version 2, which I've trumpeted as a super-duper > > > improved cherry cake, there isn't going to be any cream or even any > > > cherry.. Which cake would I rather have ? > > > > > > > > - how can I choose which filters to install when I use the RPMs > > > > > ? > > > > > > > > Simply don't install/install the xsltfilters package. > > > > And what if one needs only *one* of those filters? > > You are constructing weired scenarios. No, not weird at all. It is one which *may* arise (see below).... > Why would you only install one > single filter? I might only have a Palm, so I only need the Palm filters. In the Windows installer, that is not a problem, as I have the chance to select only that filter. > How many users do you know who did not install filters? (I'd love to > hear the reasons for not installing the filters as well) Disk space, not needing the filters, only ever going to use it for text documents... There are quite a few. With the old installer, I rarely installed any extra filters, since I have no need of them. *If* I did find a need, then it was a simple matter or running the install script, selecting "Repair" and installing the missing components.... > > > this answer is not good, > > since the method requires an "all or nothing" approach. > > And be honest: How many (clueless) users will choose not to install the > filters? And how many of those will ever need or use them? > > > > > > - where's the customized setup installation gone ? > > > > Still there in Windows, but not in Linux. The older tarball installer was > > superior in that respect. And the reason there is no longer any "Custom" > > option is plain... it is purely *because of* the RPM based packaging. > > > > Make RPM packages available by all means, but there needs to be a tarball > > (better yet, a self-extracting one) so that those who wish to may do a > > custom installation... [...] > > First define what you mean by custom installation. See the "Custom" option in the windows installer. > > > > > The customized setup has been obsoleted by different packages. Only > > > > install those components you like to have installed. This is pretty > > > > much the same as with the old setup. > > > > No it isn't... I have no idea, based on either the names or descriptions, > > which packages do what. Some sort of pre-selection script is needed... > > > > Example: If I decide I don't want to install Base, but do want Calc and > > Writer, which packages do I install? > > Simply install the base package and rpm will tell you what it needs. If > not, then it is a bug in the package. > > > Obviously there are the Writer and Calc > > RPMs, but what about the *core* RPMs? Which of them do I install? > > Well "core" suggest that these are the basis for OOo - you'll probably > need them. The reason why there are multiple packages now is to allow > smaller updates. (But not sure whether the split will stay) > > > and in what > > order? (And don't just say "urpmi will do that for you" because it > > doesn't always work correctly). > > It will. If not it is a bug. But for OOo it doesn't matter. You can > choose whatever order you like. The dependencies are runtime > dependencies. There are no dependencies during installation. Strange... When I installed it (after having updated the urpmi sources), the packages were installed in a *very* specific order, and that order was nothing like I expected... > > > > Ah, and therein lies the crunch. "Pretty much the same" isn't "the > > > same" when you live in userland. > > > > And userland is where we need to function. I am perfectly capable of > > using a CLI (and often do), but if I'm to advise of assist the general > > user, I need to know such things as the graphical toolbox, and everything > > needs to be doable *from within those graphical tools*. as soon as it > > becomes necessary to use a command-lint tool, you have lost an extremely > > large number of users. > > The users you are talking about will not need any of the advanced > fetures and can simply select the desired packages in the GUI and > install the packages. The GUI will take care of dependencies and will > suggest to add the needed ones as well (at least rpmdrake and kpackage > will do so. (note that the dependencies are not set correctly for the > core packages in the beta) And there is the problem which we are trying (unsuccessfully) to get across. How *can* the user "...simply select the desired packages..." Yes, the names seem self-explanatory, yes, urpmi *should* sort things out, but.... The old style GUI had the advantage (for the end user) that they did not need to see the underlying packages. That is why I think the best would be to make the current RPM tarball a self-extractor, very much like Sun does with the JRE RPM installer (comes as a .bin executable, which ten unpacks the RPM and calls 'rpm -i'). A similar thing which extracts the OO.o RPMs, then calls a custom front-end to urpmi where the desired modules can be selected is (IMO) the ideal way to cater for all, incorporating the best aspects of both methods. It could probably be done with other package formats equally well too. > > Be fair when argumenting. All the major distribution will provide OOo > customized/adapted for that distribution. So most of the users will use > the OOo that came with their distribution. > The large number of clueless users you're talking about will not install > developer snapshots. They should not install the beta either. And more > important: They probably will not need nor want to do a "custom > install". What is needed is a more detailed description for the packages > like "Install this package if you want to do <this and that>" to ease > the identification of the packages. So you need a self-extractor like I described above.... > > And: The old installation required the use of a cli as well (or how did > you supply the "-net" switch?) I used the provided "install" script which would execute by simply clicking on it in Konqueror.... If I didn't want the "-net- switch, I simply clicked on the "setup" script. No need for the command line even there (which was very useful to know when I was giving instructions to a newbie). > > ciao > Christian -- Alex Fisher Co-Lead, CD-ROM Project OpenOffice.org Marketing Community Contact Australia/New Zealand http://distribution.openoffice.org/cdrom/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
