To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=56985
User ccasteyde changed the following:
What |Old value |New value
================================================================================
Status|CLOSED |UNCONFIRMED
--------------------------------------------------------------------------------
Resolution|INVALID |
--------------------------------------------------------------------------------
------- Additional comments from [EMAIL PROTECTED] Sun Mar 19 05:28:32 -0800
2006 -------
I never asked for removall of native installation. I simply asked for more
flexibility, such as, at least, the ability to choose the target directory.
Maybe the described behaviour is RPM's, but this simply does not work with OO.
Let me be more precise on each of my points then.
a. The RPMs are relocatable? Really? Not convinced:
[EMAIL PROTECTED]:~/OOB680_m5_native_packed-1_fr.9011/RPMS/desktop-integration$
rpm -i openoffice.org-redhat-menus-2.0.2-3.noarch.rpm
--prefix=/home/christian/test/openoffice/
error: package openoffice.org-redhat-menus is not relocateable
(non desktop integration packages make rpm dumps core on my distro, I
therefore cannot check if they are relocatable, but at least they do not seem
to use hard coded links/config files).
Obviously, the desktop integration RPMs are not relocatable. They use symbolic
links hard coded to /opt/openoffice.org.2.0 and /etc. Moreover, when I issued
this bug (for 2.0.0 if I recall well), some scripts (soffice? .desktop files?)
where not installation directory independant (this seem to have been fixed in
2.0.2, I cannot find these files them anymore). But to close this bug, you
must at least address relocation issue for desktop integration packages.
To be complete, the main RPMs use the path "opt/openoffice.org.2.0",
preventing the user to install in another directory **without** the
"/opt/openoffice.org.2.0" prefix. At least, remove "/opt".
b and c. Second part of network installation (ie: local account installation)
is therefore still needed, for users who don't have root access, or users who
don't want to install OO system wide.
Desktop integration suppose you have root access (cf a.). Moreover, it doesn't
work for local account installations (for instance, put the files in ~/.kde
and .gnome).
This should be fixed too in desktop integration packages.
d. The user **will** be wrong if you set up traps for her. What is the goal to
have 27 different installation files, where the user simply wants to install
the software (what a simplicity! this choice will certainly not in favour of
Linux over Windows as far as installation simplicity is regarded)?
I'm not convinced that exposing internal software components with such details
is the rignt thing to do. At least, there should be 1 common RPM, 1 RPM for
each software, and desktop integration RPMs.
Finally, as far as "native install" is regarded, why not supporting all the
distributions in the world if you want to go this way?
For instance, as a Slackware user (and maybe other non-RPM and non debian
distributions users), I have to repackage the whole software (given that
distros won't, in general, make a package for each non english language
supported by OO, I can't wait for distro native packages). At least, having
the option to download a tar.gz archive would be as convenient than RPMs, for
non-supported distributions.
In short, OO 2.0 cannot be installed anymore by a non developper user on some
distributions. And even on supported distributions, it is not easy, since the
"desktop integration" part is platform dependant and is confusing. Simply
looks at the new web page that appears after OO 2.0 to explain Linux users how
it can be installed: I'm sorry, but this was far simplier before, and this
**is** a regression. At least, add some explanations in the README file!!!
---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
