Hi,
Nicolas Mailhot wrote:
Le dimanche 24 avril 2005 Ã 22:02 +0200, Mathias Bauer a Ãcrit :
M. Fioretti wrote:So you must not click something in ooo that opens an ooo specific program that messes up the system. You must make sure that the _native_ installer can present, in its package selection window, its own label/submenu of "OO.o extensions", pointing to online repositories where the stuff is already in the native format.
I don't want to discuss the pros and cons of our extension installer, but I wanted to make clear that the extension installer in OOo doesn't "mess up the system" because it doesn't even touch it. It only puts some files into the OOo folder in the users home directory. I wouldn't call this a mess.
Let's just say that linux users and sysadmins strongly disagree with you for their own reasons, that they yelled at every single software system that tried to do this very thing, and that none of the proponents of this way of working ever managed to convince them it was a good way of working, and that trying to force the issue will only result in the app-specific software updater patched out of existence on all distributions that care about oo.o.
Giving users the ability to install user-specific packages (without administrative priviledges) is a feature for users. Disabling or removing features that interfere with system management tasks is a desire of system administrators, particularly those dealing with large installs.
Both of them are useful in certain circumstances. In large deployments, allowing users to install personal add-on packages creates maintenance problems. In other circumstances it may be exactly what you want. Not all add-ons exist - or will exist - as packages, particularly not for every packaging system out there. Many applications can be installed from source or tarball to any place you want (whether /usr/local or $HOME).
The OOo add-on installer can install packages correctly for all users of the installation. You can use that manually, like you can install entire applications to /usr/local. But this is also a necessary feature to create add-on packages. Installing (some types of) OOo add-ins is not as simple as dropping some files into a directory. So to create a system package for an add-on, you use the OOo package manager to install the add-on from package script.
OOo does have features you can use for large deployments. You probably can disable the Tool - Package Manager menu item with a simple configuration file - and you can use the admin mode of the package manager to install that config file... Completely preventing user-installable add-on packages requires some more hackish changes to the OOo installation, but it can be done without changing code.
Trying to convince a Windows person we don't care about his nifty graphical installer is about as easy as convincing a smoker others may object to his smoking, I hope this time this can be resolved before people start being agressive (yes we _do_ care about this a lot and we _won't_ let software distribution get in our way like it does under windows)
Installing add-ons for end-user software is a muddy area, because it is on the borderline between end-user features and administrative tasks. My experience is that if administrators are so strict about prohibiting things that it starts to hinder users' work, they get inventive in circumventing the restrictions. And then you can manage it even less.
This holds even in corporate environments [*]. But home users who couldn't care less about manageability (or so they think) accept such restrictions even less.
[*] E.g. I once had to create a multi-user, networked application using MS Access (which of course lead to several problems later on). This was serious paid work. It had to be done in Access, because any real database or server application had to be funded by the IT department with certification procedures, etc. But local applications and fileserver-based networking could be handled by the department on its own budget and schedule. They even accepted that they had to reinstall the binaries every three months, because the IT dptmt. did a quartely 'spring clean' of the local disks ...
It took a decade but even Microsoft is belatedly realising that multiplying the ways of installing software is a _great_ recipe for getting unmanageable systems.
But the priority and tradeoffs for scalable manageability are different for different use cases.
BTW: The Linux world is a particularly difficult target for this topic. It is all nice and well to say every installable piece of software must be packaged. But when you choose some form of package someone feels left out. See the protests against us using RPM for OOo, which was chosen, because it is supported by any LSB-compliant distro. Still there are the people who say they absolutely need tgz (which does not cater for manageability at all) or deb (which really also needs an appropriate repository to do everything that's needed) or whatever else their distro favors. We support most of that at build level, so every distro can packge correctly for their clientele. But apparently there also is demand for an off-the-shelf version from OOo proper. And you can't expect that every add-on (including proprietary ones) will be packaged in the correct form by every distro.
Ciao, Joerg
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
