Re: [Monotone-devel] nvm.asio

[Ulf Ochsenfahrt]

There is also the issue with compiling monotone on 'older' platforms.
For example, I still provide packages for Ubuntu 8.04, which has an
older version of pcre. Does stripped support pcre 7.4?

-- Ulf

On Tue, Jan 27, 2009 at 5:31 PM, Zack Weinberg <address@hidden> wrote:
> (this was meant to go to the list yesterday)
>
> On Mon, Jan 26, 2009 at 8:30 AM, Markus Wanner <address@hidden> wrote:
>> Hi,
>>
>> Zack Weinberg wrote:
>>> This has been proposed several times.
>>
>> Sorry for bringing this up again, then. But I don't remember any such
>> discussion since using boost headers only.
>
> Hm, the last time I remember it coming up was at the face-to-face
> conference back in 2007(?) and of course you weren't there.  Sorry.
>
>>> There are technical reasons
>>> (having mostly to do with the complexity and abnormality of boost's
>>> build system) why it has never been done, but I do not think they are
>>> insurmountable.
>>
>> A build system? You don't need no build system for header files.
>
> I was going to say that we would at least need the logic to generate
> boost/config.hpp but it turns out that's all done with #ifdefs when
> the thing is used, which is not completely crazy as it means you can
> use one installation with many compilers.  However, I don't want to
> count on it staying that way.
>
>> Or put the other way around: what does using the system provided headers
>> buy us here? It's not like distributors gain anything by building
>> "against" system headers - unlike with libraries, where replacing the
>> library could fix security issues in monotone (as well) or some such.
>
> If we use the system provided headers, then when there is a security
> issue in boost, distributors only have to apply the patch to their
> boost package and then recompile everything that depends on it, which
> is highly automated.  If we bundle our own copy of boost headers, they
> have to keep our package on a special list of additional places to
> patch when there is a security issue in boost.
>
> Let me restate my position a different way:  I think there are
> significant advantages to shipping *none* of the libraries we depend
> on: we make life easier for Linux-style binary distributors, who only
> have to carry one copy of any given piece of source; we make life
> easier for ourselves, as we do not have to watch for new releases of
> the libraries and do the integration work; we don't have to carry
> around any pieces of the libraries' configuration scripts in our own,
> and we don't lose performance because we left that piece of the
> configuration out to save hassle (e.g. for Botan's assembly
> optimizations).
>
> There are also different, significant advantages to shipping *all* of
> the libraries we depend on (with the possible exception of zlib, which
> is so stable and so ubiquitous that no one has ever had a problem to
> date with our not shipping it): we control the exact version of each
> library we use, so we're insulated from API churn; we can apply local
> patches to fix problems that affect us, before new library versions
> come out;  we make life easier for people building from source on
> systems poor in libraries, e.g. windows.
>
> Any point in between those extremes gets the downsides of both and
> only some of the advantages of either.  In particular, we don't make
> it significantly easier for people building from source unless we ship
> all the packages, and we don't make it significantly easier for
> distributors - or ourselves - unless we ship none.
>
> I think there is a middle road, though.  Let .stripped become
> mainline.  Then we revisit the .library-build branch, where we package
> up exact copies of all the upstream libraries we depend upon, in
> sibling directories to our own code.  We can then offer two tarballs -
> the "thin" one with no upstream code, and the "fat" one that includes
> everything and builds it all from source.
>
> zw
>
>
> _______________________________________________
> Monotone-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/monotone-devel
>