Hi *, On Thu, Mar 10, 2005 at 11:52:42AM +1000, Alex Fisher wrote: > 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 : > > [...] > > 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....
? Well my version of rpmdrake could handle the dependencies properly. Probably you did not have the needed packages in a location known to rpmdrake? > > [...] > > 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/>, These are not binary packages, right? > 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, It follows the recommendations of the FHS. If you want you can create a symlink that points to /usr/local or use mound with the bind option. > and it would be nice to be able to place it into > </usr/local>... But I can't from a GIU. Again: You cannot start the old setup from the GUI. You have to use the commandline anyway (to specify the -net option) The old install-script (which is a response-file installation) already accepted a custom prefix. Whether you type in the desired patch in the promt or in some box of a graphical setup doesn't really make a difference, does it? > > > > 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).... No. You say: "We need the graphical setup for the "helpless child"" and then you argument with something only an advanced user will do. > > 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... Disk space.. You install 200+ MB and don't have 2MB left for the filters? > 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.... It was selecting "modify", not "repair"... With the rpms there is not much of a difference. You don't have to run the setup but simply install the filter-rpm. > > > 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? That is not the point. IMHO the > > > > > > - 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. These options don't make much sense. IIRC the custom setup once was introduced because some IT-magazine wrote in a review "Does not even offer a custom setup".. The options are just offered so that the user thinks he has control over the setup (yeah, those windows users always trying to "tune" their windows)... > > [...] > > 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... So what? The order is irrelevant as long all necessary packages get installed. It is up to rpm which package gets written onto the disk first. RRM knows the difference between: "Package x needs to be installed before package y can be installed" and "Package x needs to be installed in order for package y to run properly" The latter is the case with the OOo packages. You can install the packages in any order you like as long as you install the requirements as well. (you can install openofficeorg-impress (with --nodeps so that rpm doesn't complaint) and then the core packages and Impress will work or you can install the core packages and then openofficeorg-impress and Impress will work as well). > [...] > 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) How should OOo know what frontend to call? Furthermore I don't like wrapped RPMs. Usually these cannot be installed non-interactively. > 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. I don't think so. Better have a document in the package explaining the process instead of obscuring it. Good old installation instructions. Unpack the tarball and remove every rpm you don't want to install, then become root using the "su" command and run "rpm -Uhv *.rpm" as root. Type "exit" to become a regular user again. The following list will give you a description of the packages to ease your selection. core packages: needed, non optional writer -> optional, but recommended - the word processor. Install if you want to read write Text documents. calc ... testtool -> optional, install this if you want to do automated testing of OOo in order to assist in improving its quality, see http://qa.openoffice.org for mor details... pyuno -> optional, install this if you want to [...] You have to choose between one (or none) of the desktop-integration packages. These will register the OOo mime-types and set-up entries in the application-menu to launch OOo. Install the one that matches your distribution. Something like this. > > 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.... No. They need some explanations. The self-extractor is only more helpful becaue it shows descrtioptions of the components. Still the user has to decide what he wants and what he doesn't want. (when running the custom setup at all) > > 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). So. You did use the install script... But how did you customize the installation in this case? -> you did not. -> This is what I mean with fair argumentation. Don't compare peas with apples. ciao Christian -- NP: Metallica - The Shortest Straw --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
