https://bugs.documentfoundation.org/show_bug.cgi?id=89963
--- Comment #2 from [email protected] --- Some comments 1) Why cannot they simply conflict with the distro provided packages, which would be the most natural thing? Trying to install the TDF provided LibO without first removing all traces of the Debian/Ubuntu provided LibO is often the origin of weird problems anyway. This is probably particularly true when one tries to start a version and there is another one already running. Is there any reason or practical use case why the TDF LibO should be installable in parallel with the distribution one? To the best of my knowledge, no-one else who is providing packages does the same (e.g. you cannot install Mozilla's firefox in parallel with the distribution mozilla or Owncloud's Owncloud in parallel with the distribution provided one). 2) Anything that is packaged becomes in some sense system software, regardless of who provides it, as it becomes automanaged by system tools. Things start getting triggered automatically without the admin realizing it. 3) An admin may like to have in /usr/local/bin his/her own wrapper to libreoffice, or may have scripts verifying the integrity of anything that is installed there, messing with his/her own playground with packages is something that may work in 99% of cases and still cause gratuitous trouble in the remaining 1%. 4) I believe that the suggested approach to prevent collisions rather than polluting /usr/local/ is to install in opt (as you do) and have the post-installer script add a file to /etc/profile.d to update the system path so that what has just been installed can be found. -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
