[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,

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


Reply to: