Re: [Monotone-devel] Option --without-bundled-lua does not behave as expected

[Tomas Fasth]

Nathaniel Smith skrev:
> On Wed, Apr 13, 2005 at 10:57:31AM +0200, Tomas Fasth wrote:
>
>>I have been trying to convince the monotone build configuration to
>>link monotone with a shared lua library as provided by debian. I use
>>the option "--without-bundled-lua" and I have also tried
>>"--with-bundled-lua=no". I have not been able to get this to work as
>>expected so far. The source in lua subdirectory is still compiled
>>and added to "lib3rdparty.a", and it does not show up in the "ldd
>>monotone" shared library list.
>>
>>Question; Has this configure option (--without-bundled-lua) been
>>verified to work as expected?
>
>
> No, we don't really maintain those, and there's no guarantee that even
> if you got the build system to work, the result would work, since we
> sometimes make local modifications to the bundled libraries and don't
> always keep perfect track of doing so.  (In Lua's case, for example, I
> believe we diked out the "os.execute" function directly from the
> source, since it is unsafe.)

I am surprised then, that this option exists at all. May be it
should be removed, since it does not work, is not wanted, and is not
supported.

> As a general rule, you want to use the bundled libraries.  They
> work and are tested, when the upstream version might be neither.

I can see your point. Your argument make sense if you don't have a
reliable infrastructure, packaging guidelines, quality assurance or
release management.

Since Debian provides all this, I will consider your argument and
decide whether to spend time on getting an externally linked lua
shared library to work with monotone in Debian or not. If I do, I
will of course provide necessary patches to this project.

Your approach does not scale well in general, though. Individual
upstream developers (like yourself in the eyes of the Debian
project) might not care much, but in large distributions like Debian
with 9677 source packages and 16817 binaries, and counting, an
extensive use of shared libraries is very important, both from a
maintainance workload point of view as well as the security aspect.
For example, shared libraries can be subject to security fixes
independent of dynamically linked executables. In Debian, for
example, a source package is compiled for 12 different processor
architectures. Without shared libraries the workload would be so
much higher.

In Debian all packages have a responsible maintainer. The Debian
social contract makes an upload of a non-working or untested shared
library very unlikely. And even if an individual package maintainer
misbehave, the system is self healing since most other developers
will care and take action (through the Non Maintainer Upload procedure).

My point is, the argument that upstream versions of code libraries
might not work or might not be tested does seldom apply. That is,
provided that you use released versions and not snapshots, of course.

I also believe that open source and free software developers in
general will benefit more in the long run if they provide patches to
the upstream authors rather than keeping the changes to themselves.
But you know all this already.

Regards
--
Tomas Fasth <address@hidden>
GnuPG 0x9FE8D504

signature.asc
Description: OpenPGP digital signature