Hi,

It looks like libreoffice-common offers an architecture
independent interface to its users.
Would you mind setting it to Multi-Arch: foreign?
It's usually a matter of adding one line to debian/control.

This would hopefully improve install options for different
architectures.  Like running x32 tools on an amd64 system.

Note: Architecture=all packages are not Multi-Arch=foreign
automatically for various reasons, so they need to be set
manually.


Cheers

    Elrond

notfound 852326 1:5.2.4-2~bpo8+1
tag 852326 + wontfix
thanks

This BTS is not for BPO bugs. *If* you file bugs here, file them with
a proper version. The BTS does NOT know about bpo versions and gets confused.

No, it doesn't. Except maybe soffice which basically is just a wrapper
script around soffice.bin and "data"

How? You still need to have the binary "rest" for a working LO. How
would libreoffice-common on/for x32 help?

And I assume the UNO thingies will have severe problems with multi-arch
anyway.

No, won't do that.

Regards,

Rene

Hi,

Okay, will take a note for next time.

It is Architecture=all. So it is very, very likely
architecture independent, really.
There are only a few cases, where Architecture=all packages
that should not be tagged M-A:foreign.

Let's assume an amd64 system. untagged Arch=all packages
have the implicit arch of the host system, so, they are
amd64.

If you want to install libreoffice-core/x32, it depends on
libreoffice-common/x32. But libreoffice-common is only
available as /all[amd64] (see above). So you can't
install libreoffice-core/x32.

If libreoffice-common is M-A-foreign, than
libreoffice-common/all[amd64] is allowed to be used instaed
of libreoffice-common/all[x32].  Then installing
libreoffice-core would work.

The uno-libs3 package isn't a problem. The x32 one can be
installed on amd64.
Neither is ure.

The python thingies could become a problem.

This request is one step in the right direction.

I am actually trying to run different versions of LO on my
machine for different reasons. And this is currently
stopping me from doing so.

What exactly would break? What is the real problem you're
trying to avoid?

fonts-opensymbol (from the same source package) is already
marked Multi-Arch=foreign, so what's different here?

Please help me understand.


Cheers

    Elrond

Hi,

Okay, let's get this more real. My use case: Run amd64
libreoffice on an i386 system. This is a very old install
and I am trying to migrate it to amd64 step by step.

But the opposite could also be real: Having an amd64 system
and trying to run the i386 binaries. For example to test
them, without having to setup a full chroot and having to
put everything needed in the chroot.

Or having an x32 system and using libreoffice amd64 on it,
because there's no x32 one.

Anyway, let's continue:
[...]

Okay, and having enabled i386 binaries as a second allowed
arch.

So we have amd64 as primary arch and i386 as secondary.


[...]

No.

The libreoffice-common.deb is the same. True.

But libreoffice-core from the secondary arch (i386 in our
new example) depends on libreoffce-common. And it depends
on lo-common either as i386, or as all+multi-arch-foreign.
The current libreoffice-common will not fulfill that
dependency.

Yes, this is not really intuitive, because the same
packages would work on a machine, where i386 is the primary
arch. This was a long discussion, and there are complex
reasons, why this is so.

Hope it's now real enough?

But you could run the amd64 version on an x32 system, or,
or ...

I don't want to run amd64 and i386 on the same machine.

If the core answer is "Use chroots", then we should have
stopped multi-arch years ago.
Really, there's a reason, why multi-arch exists and chroots
aren't the answer to everything.

I don't think, they hurt a lot, really.

Right, dependency in cross architecture situations.
And that's exactly the same here.


Cheers

    Elrond

This can be done without multi-arch. And cross-grading while theoretically
possible is a nightmare imho :)

chroot. "Everything needed in the chroot" is base system +
LO+dependencies. Same as you would need here anyway.

For which you would need the amd64 libs, which you deny to want
exactly one step before.

You don't get what I say. If you have LO binaries on your arch you
also have lo-common. It does not matter whether it's
"on lo-common either as i386, or as all+multi-arch-foreign."

You do not need a cross-arch dependency.

Exactly my point since years. I don't see the need in multi-arch since
years.

No, it isn't.

Regards,

Rene

On Tue, Jan 24, 2017 at 17:45:18 +0100, Rene Engelhard wrote:
[...]
[...]

Okay, I do still think, that we have some technical
discrepancies in our thinkings, but from what I read here,
this can be summarized as:

You don't want to consider multi-arch at all, so you're
tagging this wontfix.

I give up here.


Cheers

Elrond

Hi,

True, but I gave in already for other packages where it might have made sense,
but in this specific case it just doesn't.

Regards,

Rene

Hi,

On Thu, Jan 26, 2017 at 12:32:58 +0100, Rene Engelhard wrote:
[...]

Thanks for the note.

I will do a local repackage and see, if it resolves the
dependency problem I am seeing.  If it does, I will be
happy for my local setups and script the repackaging for
the updates.


Cheers

    Elrond

Dear submitter,

as the package libreoffice has just been removed from the Debian archive
experimental we hereby close the associated bug reports.  We are sorry
that we couldn't deal with your issue properly.

For details on the removal, please see https://bugs.debian.org/1069123

The version of this package that was in Debian prior to this removal
can still be found using https://snapshot.debian.org/.

Please note that the changes have been done on the master archive and
will not propagate to any mirrors until the next dinstall run at the
earliest.

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmaster@ftp-master.debian.org.

Debian distribution maintenance software
pp.
Scott Kitterman (the ftpmaster behind the curtain)

Humanitarian Grant of 1.5M for you. Reply for claims