Debian Bug report logs - #695916
libreoffice-common: please use alternatives system for /usr/bin/soffice

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Luc Maisonobe <luc@spaceroots.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: libreoffice-common: libreoffice installs its own /ust/bin/soffice instead of using debian alternatives system

Date: Fri, 14 Dec 2012 11:15:21 +0100

Package: libreoffice-common
Version: 1:3.5.4+dfsg-4
Severity: normal

Dear Maintainer,

Since the fork between LibreOffice and OpenOffice.org (now Apache OpenOffice),
both suites install /usr/bin/soffice directly.
This completely prevents users to install both on the same computer, despite
Debian does provide a fully mature way
to support that: the alternatives.

This is particularly annnoying since /usr/bin/soffice is already a link, so
technically there is no point in forcing its destination
at installation.

With the current setting, attemptin to install the suite A when suite B has
been installed beforehand fails (whatever are
A and B, the problem is the same in both installation orders). The failure is
that dpkg refuses to overwrite /usr/bin/soffce since
it is own by the first package installed. Installation can be force using dpkg
only using the --force-overwrite flag. This is
really inconvenient and seems to contradict Debian installation rules. Even if
people manage to install both packages using dpkg
and --force-overwrite, upgrading also don't work and the same trick has to be
reused to overwrite the link.

LibreOffice (and Apache OpenOffice too) should use the alternative mechanism to
set up the /usr/bin/soffice link.



-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libreoffice-common depends on:
ii  dpkg                                                  1.16.9
ii  libreoffice-style-galaxy [libreoffice-style-default]  1:3.5.4+dfsg-4
ii  libreoffice-style-tango [libreoffice-style]           1:3.5.4+dfsg-4
ii  ure                                                   3.5.4+dfsg-4

Versions of packages libreoffice-common recommends:
ii  libexttextcat-data  3.2.0-2
ii  xfonts-mathml       6

Versions of packages libreoffice-common suggests:
pn  libreoffice-style-crystal     <none>
pn  libreoffice-style-hicontrast  <none>
pn  libreoffice-style-oxygen      <none>
ii  libreoffice-style-tango       1:3.5.4+dfsg-4

-- no debconf information

Message #10 received at 695916@bugs.debian.org (full text, mbox, reply):

From: Luc Maisonobe <luc@spaceroots.org>

To: 695916@bugs.debian.org

Subject: similar bug filed for Apache OpenOffice

Date: Fri, 14 Dec 2012 11:32:18 +0100

Hi,

As this bug is mainly a compatibility problem between different
packages, I have filed another report for Apache OpenOffice here:
https://issues.apache.org/ooo/show_bug.cgi?id=121481.

Message #15 received at 695916@bugs.debian.org (full text, mbox, reply):

From: Rene Engelhard <rene@debian.org>

To: Luc Maisonobe <luc@spaceroots.org>, 695916@bugs.debian.org

Cc: control@bugs.debian.org

Subject: Re: libreoffice-common: libreoffice installs its own /ust/bin/soffice instead of using debian alternatives system

Date: Fri, 14 Dec 2012 16:02:39 +0100

severity 695916 wishlist
tag 695916 wontfix
retitle 695916 libreoffice-common: pleasse use alternatives system for  /usr/bin/soffice
thanks

On Fri, Dec 14, 2012 at 11:15:21AM +0100, Luc Maisonobe wrote:
> Package: libreoffice-common
> Version: 1:3.5.4+dfsg-4
> Severity: normal

No. It's wishlist. See below.

> Since the fork between LibreOffice and OpenOffice.org (now Apache OpenOffice),
> both suites install /usr/bin/soffice directly.

Yes.

> This completely prevents users to install both on the same computer, despite

Correct.

> LibreOffice (and Apache OpenOffice too) should use the alternative mechanism to
> set up the /usr/bin/soffice link.

BTW, This is
 a) a wish
 b) not a bug in Debian in any case but a upstream one (it relies on
    a /usr/bin/soffice anyways)
 c) irrelevant in Debian as that doesn't have Apache OpenOffice packages
    (not even RFPed/ITPed)

But even then:

- how do you ensure external API stuff (especially those using new
APIs/features introduced) uses the correct soffice?
- or stuff adapted for the fixed (-- vs -, though the latter still work.)
  command line options in LO? Stuff using that will break when soffice
  points to a AOO soffice?

I don't think mangling a such-important thing like soffice is a good idea.

Regards,

Rene

Message #26 received at 695916@bugs.debian.org (full text, mbox, reply):

From: Rene Engelhard <rene@debian.org>

To: Luc Maisonobe <luc@spaceroots.org>, 695916@bugs.debian.org

Subject: Re: libreoffice-common: libreoffice installs its own /ust/bin/soffice instead of using debian alternatives system

Date: Fri, 14 Dec 2012 16:14:38 +0100

On Fri, Dec 14, 2012 at 04:02:38PM +0100, Rene Engelhard wrote:
>  b) not a bug in Debian in any case but a upstream one (it relies on
>     a /usr/bin/soffice anyways)
[...]
> - how do you ensure external API stuff (especially those using new
> APIs/features introduced) uses the correct soffice?
[...]
> I don't think mangling a such-important thing like soffice is a good idea.

To make that more clear. "UNO bootstrap" uses /usr/bin/soffice. That's why
it's there, I would more like to have it NOT in /usr/bin _at all_ as the name
already is misleading and is a remain from the prorietary *S*tar*Office*.

But no, we need to keep it and we need to make sure it is the right one
for what we ship - what we do. (This is also why libreoffice-common conflicts
openoffice.org-common)

If you want to use a "soffice" wih AOO, yes, you need to remove LO
and install OO. No one claimed those t wo are parallel-installable.

/usr/bin/soffice is not the only thing which is in the way here, anyways.

Regards,
 
Rene

Message #31 received at 695916@bugs.debian.org (full text, mbox, reply):

From: Rene Engelhard <rene@debian.org>

To: Luc Maisonobe <luc@spaceroots.org>, 695916@bugs.debian.org

Subject: Re: libreoffice-common: libreoffice installs its own /ust/bin/soffice instead of using debian alternatives system

Date: Fri, 14 Dec 2012 16:33:06 +0100

Hi,

On Fri, Dec 14, 2012 at 04:14:38PM +0100, Rene Engelhard wrote:
> To make that more clear. "UNO bootstrap" uses /usr/bin/soffice. That's why
> it's there, I would more like to have it NOT in /usr/bin _at all_ as the name
> already is misleading and is a remain from the prorietary *S*tar*Office*.
> 
> But no, we need to keep it and we need to make sure it is the right one
> for what we ship - what we do. (This is also why libreoffice-common conflicts
> openoffice.org-common)

And to make it even more clear:

http://cgit.freedesktop.org/libreoffice/core/log/?h=libreoffice-4-0&qt=grep&q=API+CHANGE

(as you see, this *will be* in LO 4.0 beginning of next year already)

What are you doing with stuff using that accessing /usr/bin/soffice
and assuming it's AOO which includes those obsolete API which would
happen if soffice was an alternative? [1]

Regards,
  
Rene

[1] There shouldn't be much using that (if at all), but it's the theory
which counts..

Message #36 received at 695916@bugs.debian.org (full text, mbox, reply):

From: Luc Maisonobe <luc@spaceroots.org>

To: 695916@bugs.debian.org

Cc: control@bugs.debian.org

Subject: Re: libreoffice-common: libreoffice installs its own /ust/bin/soffice instead of using debian alternatives system

Date: Fri, 14 Dec 2012 16:34:01 +0100

Hi Rene,

Le 14/12/2012 16:02, Rene Engelhard a écrit :
> severity 695916 wishlist
> tag 695916 wontfix
> retitle 695916 libreoffice-common: pleasse use alternatives system for  /usr/bin/soffice
> thanks
> 
> On Fri, Dec 14, 2012 at 11:15:21AM +0100, Luc Maisonobe wrote:
>> Package: libreoffice-common
>> Version: 1:3.5.4+dfsg-4
>> Severity: normal
> 
> No. It's wishlist. See below.

OK.

> 
>> Since the fork between LibreOffice and OpenOffice.org (now Apache OpenOffice),
>> both suites install /usr/bin/soffice directly.
> 
> Yes.
> 
>> This completely prevents users to install both on the same computer, despite
> 
> Correct.
> 
>> LibreOffice (and Apache OpenOffice too) should use the alternative mechanism to
>> set up the /usr/bin/soffice link.
> 
> BTW, This is
>  a) a wish

OK with that.

>  b) not a bug in Debian in any case but a upstream one (it relies on
>     a /usr/bin/soffice anyways)

b1) the Debian policy is to file bug against Debian first, not to
    upstream. It is the responsibility to the packaging team to forward
    it upstream if needed, not to the original reporter
b2) in many other packages, Debian packagers choose to adapt what is
    provided upstream, so it is a packaging decision. I'm not claiming
    it is a right or wrong decision (I do not have the necessary
    background for that). I just want to make clear that you do have
    this choice and decided to preserve this link in your packaging.
b3) I did not ask to remove this link, I asked for this link to be set
    up according to the alternatives mechanism which is Debian standard

>  c) irrelevant in Debian as that doesn't have Apache OpenOffice packages
>     (not even RFPed/ITPed)
> 
> But even then:
> 
> - how do you ensure external API stuff (especially those using new
> APIs/features introduced) uses the correct soffice?
> - or stuff adapted for the fixed (-- vs -, though the latter still work.)
>   command line options in LO? Stuff using that will break when soffice
>   points to a AOO soffice?

I am not assuming any of these. There are legitimate use that many users
would find helpful. Just being able to launch one of the program using
mime type from a file explorer (say gnome nautilus) for example does not
use any custom flag. So for such uses (which correspond proably to 99%
of the uses), letting the user make his own choices would be nice.

But even then, for use that require a specific version would of course
not rely on the anonymous link but rather on the specific target of the
link (or use loffice link). Relyng on an historical link for such thing
would of course be an error.

This is exactly what the alternatives system is used for. For really
simple things like launching a program perhaps with one file argument,
the common link that can be provided by several programs is good, so
people do not need to care about that. For more complex thing were
people really need to know which program they use, and since they are
power user they *do* need to have several alternatives installed, the
link is not useful. But here, the current behaviour completely prevent
installation!

I am not claming the two suites can be completely replaced by one other,
and in fact it is even exactly my point: I need to have the two
installed *because* they are not the same. I don't mess with the link
and would be more than happy than this link disappear. But now, a link
that is not useful prevents installation.

> 
> I don't think mangling a such-important thing like soffice is a good idea.

I don't think fighting against users to prevent them doing their own
choices as responsible people is a good choice either.

Couls you please reconsider this wish.

> 
> Regards,
> 
> Rene

Message #41 received at 695916@bugs.debian.org (full text, mbox, reply):

From: Rene Engelhard <rene@debian.org>

To: Luc Maisonobe <luc@spaceroots.org>, 695916@bugs.debian.org

Subject: Re: libreoffice-common: libreoffice installs its own /ust/bin/soffice instead of using debian alternatives system

Date: Fri, 14 Dec 2012 16:46:40 +0100

Hi,

On Fri, Dec 14, 2012 at 04:34:01PM +0100, Luc Maisonobe wrote:
> b1) the Debian policy is to file bug against Debian first, not to
>     upstream. It is the responsibility to the packaging team to forward
>     it upstream if needed, not to the original reporter

And guess what? I  think that this is nonsense for bugs clearly in the
upstream domain. And I won't forward bugs I don't consider nonsense
either way.

> b3) I did not ask to remove this link, I asked for this link to be set
>     up according to the alternatives mechanism which is Debian standard

for stuff with *EXACTLY THE SAME INTERFACE*. Which is not true between
AOO and LO (anymore).

> I am not assuming any of these. There are legitimate use that many users
> would find helpful. Just being able to launch one of the program using
> mime type from a file explorer (say gnome nautilus) for example does not
> use any custom flag. So for such uses (which correspond proably to 99%
> of the uses), letting the user make his own choices would be nice.

Correct. But that shouldn't use soffice (and no menu entry does.)
and LOs mimetype entries have the -- form, so they *ARE* going to break
when the alternatives points to something else.

Would you like soffice being a alternaive but becauseof the incompatibility
stuff using it conflicting against "openoffice"? Wouldn't help you
instead of making the problem even more complex to solve.

> But even then, for use that require a specific version would of course
> not rely on the anonymous link but rather on the specific target of the
> link (or use loffice link). Relyng on an historical link for such thing
> would of course be an error.

The problem is that the programmer using the API doesn't do it
him-/herself. AOO/LOs libraries do it in bootstrap somehow. The programm,er
has no influcene here:

rene@frodo:~/LibreOffice/libreoffice-4-0/core$ grep -r soffice sal* cppu*
sal/qa/osl/profile/osl_old_testprofile.cxx:    rtl_uString_newFromAscii(&ustrProfileName,"//./tmp/soffice.ini");
sal/qa/osl/profile/osl_old_testprofile.cxx:    rtl_uString_newFromAscii(&ustrProfileName2,"//./tmp/not_existing_path/soffice.ini");
sal/osl/unx/salinit.cxx:    // On Mac OS X, soffice can restart itself via exec (see restartOnMac in
sal/osl/unx/salinit.cxx:    // of processes here, not just soffice, but hopefully none of our processes
sal/osl/unx/profile.c:#define SVERSION_PROFILE    "sofficerc"
sal/osl/unx/signal.c:static sal_Bool is_soffice_Impl (void)
sal/osl/unx/signal.c:        idx = rtl_str_indexOfStr (rtl_string_getStr (strProgName), "soffice");
sal/osl/unx/signal.c:    if (is_soffice_Impl())
sal/osl/unx/signal.c:       crash soffice re-execs itself from within the signal handler, so the
sal/osl/unx/signal.c:       second soffice would have the guilty signal blocked and would freeze upon
sal/osl/w32/profile.cxx:#define SVERSION_PROFILE    "soffice.ini"
sal/osl/w32/profile.cxx:        /* if we have not product identfication, do a special handling for soffice.ini */
cppuhelper/Module_cppuhelper.mk:	StaticLibrary_findsofficepath \
cppuhelper/source/bootstrap.cxx:#include "cppuhelper/findsofficepath.h"
cppuhelper/source/bootstrap.cxx:                OUSTR("no soffice installation found!"));
cppuhelper/source/bootstrap.cxx:                OUSTR("bad characters in soffice installation path!"));
cppuhelper/source/bootstrap.cxx:                OUSTR("cannot convert soffice installation path to URL!"));
cppuhelper/source/bootstrap.cxx:            OUString(path + "soffice").pData, ar_args, ARLEN( ar_args ),
cppuhelper/source/findsofficepath.c: * <p>An installation is found, if the executable 'soffice' or a symbolic link
cppuhelper/source/findsofficepath.c:        /* construct soffice file path */
cppuhelper/source/findsofficepath.c:        /* check existence of soffice file */
cppuhelper/Package_inc.mk:$(eval $(call gb_Package_add_file,cppuhelper_inc,inc/cppuhelper/findsofficepath.h,cppuhelper/findsofficepath.h))
cppuhelper/Library_cppuhelper.mk:	findsofficepath \
cppuhelper/inc/cppuhelper/findsofficepath.h:/* Internal function to find an soffice installation.
cppuhelper/StaticLibrary_findsofficepath.mk:$(eval $(call gb_StaticLibrary_StaticLibrary,findsofficepath))
cppuhelper/StaticLibrary_findsofficepath.mk:$(eval $(call gb_StaticLibrary_use_packages,findsofficepath,\
cppuhelper/StaticLibrary_findsofficepath.mk:$(eval $(call gb_StaticLibrary_add_cobjects,findsofficepath,\
cppuhelper/StaticLibrary_findsofficepath.mk:	cppuhelper/source/findsofficepath \

Note the static "soffice" in bootstrap.cxx.

> This is exactly what the alternatives system is used for. For really
> simple things like launching a program perhaps with one file argument,
> the common link that can be provided by several programs is good, so
> people do not need to care about that. For more complex thing were

No, it isn't.

Guess why gcc isn't an alternaive? For a similar reason. (Reproducible
builds, standard library incompatibilities, etc.)

> I don't think fighting against users to prevent them doing their own
> choices as responsible people is a good choice either.

I am purely argumenting with possible breakages in stuff which is inside
Debian. Which we also shouldn't do.

> Couls you please reconsider this wish.

No.

Regards,
 
Rene

Message #46 received at 695916@bugs.debian.org (full text, mbox, reply):

From: Rene Engelhard <rene@debian.org>

To: Luc Maisonobe <luc@spaceroots.org>, 695916@bugs.debian.org

Subject: Re: libreoffice-common: libreoffice installs its own /ust/bin/soffice instead of using debian alternatives system

Date: Fri, 14 Dec 2012 18:11:26 +0100

Hi,

On Fri, Dec 14, 2012 at 04:46:39PM +0100, Rene Engelhard wrote:
> On Fri, Dec 14, 2012 at 04:34:01PM +0100, Luc Maisonobe wrote:
> > b1) the Debian policy is to file bug against Debian first, not to
> >     upstream. It is the responsibility to the packaging team to forward
> >     it upstream if needed, not to the original reporter
> 
> And guess what? I  think that this is nonsense for bugs clearly in the
> upstream domain. And I won't forward bugs I don't consider nonsense
> either way.

s/don't/do/.

And in this case I wouldn't even expect upstream "packages" to use the alternatives
system. They only ship "their" stuff, alternatives would be the distributions' job...

Regards,
  
Rene

Message #57 received at 695916-done@bugs.debian.org (full text, mbox, reply):

From: Stéphane Aulery <lkppo@free.fr>

To: control@bugs.debian.org, 695916-done@bugs.debian.org

Cc: luc@spaceroots.org

Subject: forwarded 695916 https://bz.apache.org/ooo/show_bug.cgi?id=121481

Date: Wed, 24 Feb 2016 20:52:50 +0100

forwarded 695916 https://bugs.documentfoundation.org/show_bug.cgi?id=98157
tags 695916 + upstream
stop
-----

Hello,

I think this problem must be addressed by upstream, because it’s its 
choise to fork and it must provide an installable system, without 
confict on all systems, not only Debian.

So I filled a bug report against LO bugtracker, and I close this bug.

Regards,

-- 
Stéphane Aulery

Message #58 received at 695916-done@bugs.debian.org (full text, mbox, reply):

From: Stéphane Aulery <lkppo@free.fr>

To: 695916-done@bugs.debian.org

Subject: Close 695916

Date: Fri, 26 Feb 2016 21:01:27 +0100

Hello,

I close this bug which is irrelevant since OpenOffice has been removed 
from testing/unstable :

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706870

Regards,

-- 
Stéphane Aulery

Send a report that this bug log contains spam.