> 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 _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
