On Thu, 2012-04-26 at 11:43 +0200, Petr Mladek wrote:
Well, how many internal libraries have an important fix? Just a quick
look and I see:
Lets discuss this at the ESC call today to avoid excessive
bike-shedding :-) it's on the agenda.
Thanks,
Michael.
--
Hi,
We should not prefer system libraries if the internal copy has an important
fix.
The interesting question now is: what qualifies an 'important fix' ?
IMHO, when the current stable release is really broken.
But: in this case, most likely, the distros will clean up the mess anyways,
so
Lubos Lunak píše v Út 24. 04. 2012 v 17:16 +0200:
On Tuesday 24 of April 2012, Caolán McNamara wrote:
On Tue, 2012-04-24 at 11:49 +0200, Lubos Lunak wrote:
Right now all those 100 developers have to have a long list of options,
half of them because they are needed, other half because
On Tuesday 24 of April 2012, Caolán McNamara wrote:
On Tue, 2012-04-24 at 17:16 +0200, Lubos Lunak wrote:
Running ./autogen.sh --with-system-libs fails as soon as it finds one
external library that does not exist system-wide (and there's pretty much
bound to be one, given what all kinds of
On Wed, Apr 25, 2012 at 03:01:16PM +0200, Lubos Lunak wrote:
Is there any reasonable use case for preferring almost all internal copies
of
libraries if the system-wide one is suitable?
mu(*). You are asking the wrong question. The problem is that is suitable is
not something that is easily
On Wednesday 25 of April 2012, Bjoern Michaelsen wrote:
On Wed, Apr 25, 2012 at 03:01:16PM +0200, Lubos Lunak wrote:
Is there any reasonable use case for preferring almost all internal
copies of libraries if the system-wide one is suitable?
mu(*). You are asking the wrong question.
No,
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
On 04/25/2012 05:05 PM, Lubos Lunak wrote:
The choice has already been made, and it's whatever we ship as our internal
...more or less intensively patched...
copies.
(At least, this was a real problem in the past, when people thought they
could replace LO's -- or, back then, OOo's
(*) While this can (and did) happen just by changes in the package
itself,
automagically toggling configure-output is severly raising the risk.
ACK. Build processes should be as predictable and deterministic as possible.
Optimally, it should be a function (in mathematical terms) with as few
On Tue, 2012-04-24 at 10:24 +0300, Tor Lillqvist wrote:
I am once again pretty confused.
From a high-level point of view, what is the intent:
- Should a new, naïve contributor be able to run just ./autogen.sh
without any options and, assuming his platform is a reasonably well
supported
On Tue, Apr 24, 2012 at 10:24:33AM +0300, Tor Lillqvist wrote:
From a high-level point of view, what is the intent:
Provocative reply: Keep backwards compatibility with libreoffice-build/go-oo
concepts. They were migrated over from there.
- Should a new, naïve contributor be able to run just
2012/4/24 Bjoern Michaelsen bjoern.michael...@canonical.com:
In theory yes, in practice you will risk an endless bikeshedding fight over
some enable/disable switch defaults. Having these .conf files might help a bit
there.
To avoid bikeshed here we could do automagic approach.
All switches
On Tue, 2012-04-24 at 10:18 +0200, Bjoern Michaelsen wrote:
possibly we could also add something like:
FedoraDev.conf
...
Personally I wouldn't bother. ./autogen.sh should give a generic
configuration out of the box while something like a FedoraDev would
map to the set of configure options
On Tue, 2012-04-24 at 10:31 +0200, Tomáš Chvátal wrote:
All switches are by default on enable state and we check for the deps.
If the damn deps are not present on the system we switch the feature
off.
Some packages do this, and it leads to the nightmare situation that you
silently get a
On Tuesday 24 of April 2012, Caolán McNamara wrote:
On Tue, 2012-04-24 at 10:31 +0200, Tomáš Chvátal wrote:
All switches are by default on enable state and we check for the deps.
If the damn deps are not present on the system we switch the feature
off.
Some packages do this,
Isn't that
I wonder, by the way, if we really need to have all the
configurability we currently have... To keep bringing up the cairo
canvas as an example: if it works, why wouldn't it be enabled all the
time on Unix?
--tml
___
LibreOffice mailing list
On Tue, Apr 24, 2012 at 09:57:37AM +0100, Caolán McNamara wrote:
Some packages do this, and it leads to the nightmare situation that you
silently get a different result depending on what packages you happen to
install.
Agree, that indeed is a nightmare. What could still work is:
./autogen.sh
Tor Lillqvist wrote:
I wonder, by the way, if we really need to have all the
configurability we currently have...
As generic as the question is: probably not.
To keep bringing up the cairo canvas as an example: if it works,
why wouldn't it be enabled all the time on Unix?
Why not? The work
On Tue, 2012-04-24 at 11:49 +0200, Lubos Lunak wrote:
On Tuesday 24 of April 2012, Caolán McNamara wrote:
On Tue, 2012-04-24 at 10:31 +0200, Tomáš Chvátal wrote:
All switches are by default on enable state and we check for the deps.
If the damn deps are not present on the system we switch
On Tue, Apr 24, 2012 at 03:45:38PM +0200, Thorsten Behrens wrote:
Tor Lillqvist wrote:
I wonder, by the way, if we really need to have all the
configurability we currently have...
As generic as the question is: probably not.
As someone who does releases on a fixed schedule, I find quite a
On Tuesday 24 of April 2012, Caolán McNamara wrote:
On Tue, 2012-04-24 at 11:49 +0200, Lubos Lunak wrote:
Right now all those 100 developers have to have a long list of options,
half of them because they are needed, other half because they'd prefer
not to build repeatedly stuff they already
Running ./autogen.sh --with-system-libs fails as soon as it finds
one external library that does not exist system-wide (and there's pretty
much bound to be one, given what all kinds of libs we use).
build as an user which does not have additional (local) libraries installed ?
So one has to
On Tue, 2012-04-24 at 17:16 +0200, Lubos Lunak wrote:
Running ./autogen.sh --with-system-libs fails as soon as it finds one
external library that does not exist system-wide (and there's pretty much
bound to be one, given what all kinds of libs we use)
Aha, so I suspect this boils down to
23 matches
Mail list logo
