[arch-dev-public] testing splitted LibreOffice 3.4.2rc1

[Andreas Radke]

Am Tue, 19 Jul 2011 11:49:22 -0500
schrieb Dan McGee <dpmcgee at gmail.com>:

> Are we switching our name to Debian or Ubuntu too? This is a tad out
> of character, and I'm not a big fan at all. Not only does the
> upgrade/update fail for me, I believe I'm going to be left with a
> broken install as writer, calc, etc. aren't even pulled in for me even
> though I had them installed before.
> 
> -1, no signoff from me if I can't even do a clean update. What on
> earth problem are we trying to solve here? If you install an office
> suite, I really don't think we should be fretting over saving a couple
> of MB. This package already sees extremely frequent updates so
> bandwidth concerns far outweigh any installed size concerns.
> 
> -Dan

That's not fair. LibreOffice is mainly driven by its main supporters:
SuSE/Fedora/Debian/Ubuntu. And they all split the packages. We had that
request many times in our tracker and in our forum. And finally we are
now back "more upstream" way again.

> 
> 
> :: Replace libreoffice with testing/libreoffice-common? [Y/n] y
> resolving dependencies...
> :: There are 103 providers available for libreoffice-langpack:
> :: Repository testing
>    1) libreoffice-af  2) libreoffice-ar  3) libreoffice-as  4)
> libreoffice-ast  5) libreoffice-be  6) libreoffice-bg  7)
> libreoffice-bn  8) libreoffice-bo  9) libreoffice-br  10)
> libreoffice-brx
...
> Enter a number (default=1): 22
> looking for inter-conflicts...
> error: unresolvable package conflicts detected
> error: failed to prepare transaction (conflicting dependencies)
> :: libreoffice-common and libreoffice are in conflict (go-openoffice)
> 

This should be solved with 3.4.2rc2-1 that has libreoffice-common
providing 'libreoffice'. The upgrade path should now be smooth expect
when you use some AUR extensions or unsupported langpacks.

The install msg should say it clearly what packages you may want to
install to get the functionality you want. I find this more Arch way
than the all-in-one pkg we had so far.

Upstream made this pkg splitting now usable and recommended for all
distributions. There's no need to ship a single bloated pkg with en_US
included that many people don't want.

-Andy