[arch-dev-public] testing splitted LibreOffice 3.4.2rc1
dpmcgee at gmail.com
Tue Jul 19 14:53:11 EDT 2011
On Tue, Jul 19, 2011 at 1:22 PM, Andreas Radke <a.radke at arcor.de> wrote:
> 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.
> 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)
>> 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.
I'm not understanding you here- it clearly isn't a clean upgrade path
on my system. I have libreoffice installed now, not go-openoffice.
Your dependencies are busted. Pacman now defaults to an
already-installed provider, and because the new
testing/libreoffice-extension-oooblogger depends on 'libreoffice'
rather than 'libreoffice-common', the upgrade path doesn't work. This
needs to be fixed.
$ pacman -Si testing/libreoffice-extension-oooblogger
Repository : testing
Name : libreoffice-extension-oooblogger
Version : 3.4.2rc1-1
URL : http://www.libreoffice.org/
Licenses : LGPL3
Groups : libreoffice-extensions
Provides : None
Depends On : libreoffice coreutils python
Optional Deps : None
Conflicts With : None
Replaces : None
Download Size : 8.00 KiB
Installed Size : 44.00 KiB
Packager : Andreas Radke <andyrtr at archlinux.org>
Architecture : x86_64
Build Date : Mon 18 Jul 2011 05:06:55 PM CDT
MD5 Sum : 8132dfbc67b5a01de4e6a31b502b25df
Description : An extensions for blogging
> 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.
OK, I couldn't get that far. If it does, then I find that somewhat
more palatable, but this is still going to result in a lot of
confusion, bug reports, and forum/ML posts.
> 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.
We're not "all distributions", we're Arch.
* Old libreoffice package: 283975.00 KiB
* New libreoffice-common + -writer + -calc (what most would consider
the bare minimum) : 223474.00 + 10076.00 + 15742.00 = 249292.00 KiB,
which is 87% of the size of the old package.
I guess we have different definitions of "bloated package". I'm also
trying to figure out the value added by having a 44 KiB installed
'libreoffice-draw' and 736 KiB installed 'libreoffice-impress' package
that I have to remember to install separately.
More information about the arch-dev-public