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
- Re: distro-configs files, autogen.sh options, defaults etc (continued)
- Re: distro-configs files, autogen.sh options, defaults etc · Caolán McNamara
- Re: distro-configs files, autogen.sh options, defaults etc · Lubos Lunak
- Re: distro-configs files, autogen.sh options, defaults etc · Bjoern Michaelsen
- Re: distro-configs files, autogen.sh options, defaults etc · Lubos Lunak
- Re: distro-configs files, autogen.sh options, defaults etc · Stephan Bergmann
- Re: distro-configs files, autogen.sh options, defaults etc · Petr Mladek
- Re: distro-configs files, autogen.sh options, defaults etc · Michael Meeks
- Re: distro-configs files, autogen.sh options, defaults etc · Enrico Weigelt
- Re: distro-configs files, autogen.sh options, defaults etc · Bjoern Michaelsen
- Re: distro-configs files, autogen.sh options, defaults etc · Enrico Weigelt
- Re: distro-configs files, autogen.sh options, defaults etc · Enrico Weigelt
- Re: distro-configs files, autogen.sh options, defaults etc · Petr Mladek
Re: distro-configs files, autogen.sh options, defaults etc · Tor Lillqvist
Re: distro-configs files, autogen.sh options, defaults etc · Bjoern Michaelsen
Re: distro-configs files, autogen.sh options, defaults etc · Caolán McNamara
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.