monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Re: bundled libs


From: Daniel Carosone
Subject: Re: [Monotone-devel] Re: bundled libs
Date: Mon, 18 Feb 2008 18:15:13 +1100
User-agent: Mutt/1.5.17 (2007-11-01)

On Mon, Feb 18, 2008 at 07:45:01AM +0100, Markus Schiltknecht wrote:
>
> So, isn't the question right now: shall we continue to maintain our own 
> copy of those things at all?

A valid question, but one I'll not directly address right now.  

I'm happy to start with the ability to use system copies of libs under
packaging control, and leave the vendor-branch-maintenance and
self-building discussion to those undertaking that work.  I do wonder
idly at the implications for the all-in-one static linux binary we
offer, or for that matter the Windows install, but again that's not
something I have any involvement with to comment.

> Of course, testing with different botan, sqlite and pcre libraries doesn't 
> come for free. 

I suggest that this becomes part of the scope of having a sufficient
diversity of buildbot coverage; a current problem, but one for which
solutions will bring other benefits as well.

I'm happy to back this suggestion with a committment to finally get
off my butt and set up some more bots on platforms I care about.  It
would be especially nice (and more helpful at scale) if someone wanted
to tidy/finish/organise the bot infrastructure/tool/version issue,
too.

> And maybe, one day we need to differentiate between certain 
> versions of these libraries or drop support for old versions. But hey, 
> that's a well known process to pretty much everybody involved.

Agreed; we merely ned to publish these requirements - in
human-readable form in the release notes, and optionally also in the
various distribution-metadata formats for packaging systems we want to
maintain build info for directly.

> Agreed, for a new user it's a bigger hurdle, if he has to install other 
> libraries first. However, most package systems cover that pretty 
> automatically. 

Some systems don't really have native packaging mechanisms, or they
have rather poor ones; many of these platforms are supported by
pkgsrc.  Some other systems have awkward reasons why they can't be
upgraded; that's a tougher nut, and part of the reason why we offer
static binaries, but I think we need to stop letting these
(diminishing) corner cases dictate our common practice.

--
Dan.

Attachment: pgpvaK4gBU4IP.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]