distro-configs files, autogen.sh options, defaults etc

[Enrico Weigelt]

> 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