* Caolán McNamara caol...@redhat.com schrieb:
Trivial: your own microdistro. (prefix build approach, etc).
Honestly, how is that supposed to work.
With Briegel: quite simple.
Just properly state the dependencies in the package descriptors,
tell the target-config to use different
* Michael Meeks michael.me...@novell.com schrieb:
Luckily we have a micro-distro now; complete with our own build system,
and method of packaging; it is called the onebigblob microdistro - and
it works as badly as can be expected when trying to target all distros.
No. It works as good
On Sun, 2011-01-30 at 22:11 +0100, Enrico Weigelt wrote:
No, simply state the depencies and let the distros handle the rest.
For old legacy systems, simply create an own micro-distro.
Luckily we have a micro-distro now; complete with our own build system,
and method of packaging; it is
On Sat, 2011-01-29 at 14:44 +0100, Francois Tigeot wrote:
I'm still trying to figure out the autogen.sh stuff and make it use the
correct paths for libraries; one of the errors I got is really freaking
me out:
:-)
Why would LO need to build it own version of Mozilla/Seamonkey !?
On Mon, 2011-01-31 at 13:30 +, Michael Meeks wrote:
and xml security foo - AFAIR the cert management
stuff in moz really needs pushing down to NSS, or splitting out.
IIRC the real stuff that xmlsecurity needs is all in NSS, while the only
bit that xmlsecurity needs from MOZ is simply to
On Mon, 2011-01-31 at 14:38 +, Caolán McNamara wrote:
On Mon, 2011-01-31 at 13:30 +, Michael Meeks wrote:
and xml security foo - AFAIR the cert management
stuff in moz really needs pushing down to NSS, or splitting out.
IIRC the real stuff that xmlsecurity needs is all in NSS,
On Mon, Jan 31, 2011 at 01:27:07PM +, Michael Meeks wrote:
Francois: I expect you to google Tor Lillqvist, and think a bit more
before typing.
I'm sure Tor is a nice fellow; I'm sorry if some of my mails seemed rude,
that was not my intent.
this does not
mean it is worthless having
On 31/01/11 00:32, Enrico Weigelt wrote:
Little bit trickier when putting on a ISV hat and trying to target
all Linux distros
One binpkg for all distros ?! The whole idea of this is stupid.
Some of my customers didn't listen to me and tried that at any
cost, they failed miserably. I haven't
On Sat, 2011-01-29 at 14:00 +0100, Enrico Weigelt wrote:
Hi folks,
one of the things which always unnverved me most in OO is the fact
that it ships own copies of dozens of standard 3rd-party packages,
often very outdated and patched-to-death.
For a distro build configuring with
* Tor Lillqvist tlillqv...@novell.com schrieb:
Please, are you talking about third-party source code included
in the LibreOffice source code (git repositories), source code
downloaded as part of the build process (unless one tells it
to use a system library), or binaries from either of those
* Francois Tigeot ftig...@wolfpond.org schrieb:
Should LO be including 3rd party software to facilitate the work of people who
don't know what they are doing ?
At the cost of everybody else ? (from devs through package/dist maintainers
to end users who all have to waste lots of their
* Caolán McNamara caol...@redhat.com schrieb:
For a distro build configuring with --with-system-libs will generally
do-the-right-thing.
What happens when the software depends on some ancient, long solved
bug that's maybe still in the old bundled version ? You'll have to
support both the
On Sun, 2011-01-30 at 22:26 +0100, Enrico Weigelt wrote:
* Caolán McNamara caol...@redhat.com schrieb:
For a distro build configuring with --with-system-libs will generally
do-the-right-thing.
What happens when the software depends on some ancient, long solved
bug that's maybe still in
* Caolán McNamara caol...@redhat.com schrieb:
That's the argument in favour for using --with-system-libs and its
definitely the right choice for distros.
The right choice for everybody who's not completely lobotomized ;-P
Little bit trickier when putting on a ISV hat and trying to target
Hi folks,
one of the things which always unnverved me most in OO is the fact
that it ships own copies of dozens of standard 3rd-party packages,
often very outdated and patched-to-death. Obviously this is a
nightmare for package engineering.
I'm currently in process of identifying those and
it ships own copies of dozens of standard 3rd-party packages,
standard from the viewpoint of up-to-date Linux distros, that is. Don't
forget that LibreOffice is supposed to run also on not-so-up-to-date Linux
installations. (As far as I know, the generic Linux build of LibreOffice is, or
am I
Hi,
On Sat, Jan 29, 2011 at 04:59:27PM +0100, Rene Engelhard wrote:
On Sat, Jan 29, 2011 at 08:36:35AM -0700, Tor Lillqvist wrote:
it ships own copies of dozens of standard 3rd-party packages,
standard from the viewpoint of up-to-date Linux distros, that is. Don't
forget that
Hi,
On Sat, Jan 29, 2011 at 08:36:35AM -0700, Tor Lillqvist wrote:
And of course, various other Unixes too (although I don't know if we have any
active builders/packagers except for BSDs), on which one can be even les sure
that there are up-to-date standard 3rd-party packages available.
On Sat, Jan 29, 2011 at 08:36:35AM -0700, Tor Lillqvist wrote:
it ships own copies of dozens of standard 3rd-party packages,
standard from the viewpoint of up-to-date Linux distros, that is. Don't
forget that LibreOffice is supposed to run also on not-so-up-to-date Linux
installations.
* Francois Tigeot ftig...@wolfpond.org schrieb:
There are all sorts of solutions:
- using the vendor framework (if they still care/are alive)
- installation by hand (configure / make / make install)
- lightweight management with tools such as stow:
IMHO, there's no reason to include old versions of third-party packages in
LibreOffice proper.
Please, are you talking about third-party source code included in the
LibreOffice source code (git repositories), source code downloaded as part of
the build process (unless one tells it to use a
21 matches
Mail list logo
