Date: prev next · Thread: first prev next last
2012 Archives by date, by thread · List index



mu(*). You are asking the wrong question. The problem is that "is
suitable" is
not something that is easily decidable. Even less so by configure
automagic. It
often boils to making the choice between two sets of bugs (or a set
of bugs vs.
one big blocker).

Well, this is a problem of exponential complexity.

The only practically managable way to solve this (given the limited
resources) is leaving this to the distros. They already have their
infrastructures and resources to maintain thousands of packages
in their various combinations. If a project like LO wants to handle
this problem entirely on its own, this essentially means duplicating
such distro infrastructures.

So my clear vote is, dropping all bundled 3rdparty packages,
import them via standard mechanisms (pkg-config, etc) and leave
the rest to the distros.

Now there are several cases to cope with:

a) $distro lacks some packages (unlikely for the major distros)

-> step into the package maintainer role for those packages in
that $distro and provide packages there.

b) $distro doesnt keep up w/ LO upstream fast enough, so users
might miss some features

-> step into the package maintainer role for LO in $distro and
provide newer packages (most of it can be automatized)

note: $distro might have good reasons for being slow at this point
(eg. Ubuntu prefers stability over features). in this case, your
newer LO packages might make it directly into the distro's official
repository, but then we still can maintain our own vendor repository.

c) certain people might want an fully self-contained packages,
for environments that live completely out of any distro context
(mostly: esoteric operating systems, like windows, that don't
even know the fundamental concepts of package management and
distros)
-> roll your own micro-distro
-> set up an build environment (eg. via chroot or sysroot'ed crosscompiler)
that builds all required source packages (along the dependency graph)
and bundles the output to one big binary package, that's going to be
deployed in some different area (on unix-alike platforms that would be
something like /opt/libreoffie/)


In my professional carreer I already had several similar scenarios in
various customer projects. Those who followed my advise, had a mid-
and long-term hr saving in the scale 20..30% (after a few man-weeks
initial efforts for the transition, of course), others who didn't
follow me, still have contigiously increasing maintenance overhead.


cu

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.