[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



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


Reply to: