Re: Help wanted: simple tasks

Damián Viano wrote:
> On Wed, Feb 21, 2007 at 06:50:29PM -0500, Mark Neill wrote:
[...]
>> Any libraries, in CenterICQ's case, should be included in the source.
>                                             ^NOT
>> These libraries are not like, say, libc, or imlib, or libraries which are 
>> shared across a system; they're development-only libraries which are going 
>> to be wrapped in CICQ to present a unified code and interface front-end to 
>> the user.  Users shouldn't be responsible for having to track down the 
>> difference in arcane internal versions of 0.9.3b and 0.9.4q of chatlib-dev 
>> in order to compile CICQ, nor as maintainers would you want the headache 
> 
> This is a task for each distro maintainer (and I speak as one, not of
> centericq anyway) IF a user want to compile cicq by himself, he should
> expect the need to download some specific dev libraries.
> 
> Also this is why we have SONAME versions and dynamic linkers, come on,
> this is like saying every user app should be built statically for the
> sake of simplicity and reproducibility.
> 
>> of trying to figure out every difference between what CVS is built against 
>> and what Joe User who just installed RedHat7 on his old PC is running.
>>
>> Users probably aren't going to be using these libraries on their system 
>> for anything _except_ building CICQ - so give them the library we want 
>> them to use.  If they want to write their own Jabber client, let them go 
>> grab libjabber-dev from apt.
> 
> You are just assuming your use case is the general instead of thinking
> pro flexibility IMO.

I agree with what you've written above.


>> If they're dead libraries, they're dead.  If they work, it doesn't much 
>> matter.  The problem will be when, 6 months from the next release, 
>> libgadugadu stops working against the latest releases of the Gadu servers 
>> in the wild, and no one is working on the library any more to fix it.  If 
>> we can fix it, hooray,
> 
> In which case is better to adopt the library and maintain it for the
> hole FS community instead of just using a self patched library which
> many others may need and not found because is buried in some other
> project SCM.

I'd vote for providing adapted versions of used libraries which won't be
available on their official sites but alongside cicq instead of within
the official cicq tarball. This would include separating the library
source from the cicq repository module (whatever it might be called by
git) into a separate one.
So we would have everything needed in one place, except actively
maintained libs which should, at least for me, stay separate.

The same would apply to adopted libraries.


>> if not, then we need to be able to drop in a new 
>> library to make CICQ work again.  In which case, we're back to "include 
>> the libraries we want users to use" again.
> 
> Really? big SCM diffs importing sources from other projects instead of
> just small diff on autotools and documentation? I don't think that's a
> vote for "include the libraries we want users to use"
> 
> Also as seen keeping libraries within the sources is a security hell,
> a maintainer burden and just bloat the codebase to the only win of
> 'simpler build'.
> 
> My call is: if you want it simple, use a binary distro and let the
> maintainer handle the burden, if you want it rough be sure you can
> handle getting some specific versions of libraries.
[...]

Besides, no one keeps us from providing separate all-inclusive packages
which include the library source. This would enable the user/distributor
to decide if he wants a monolithic package or a modular one.

It should be possible to unify the build process of the different cicq
packages with autoconf so that plain cicq needs the external libraries
and the all-in-one version can choose between bundled or separately
installed ones.


Regards,
Andi
_______________________________________________
Cicq mailing list
[email protected]
http://mailman.linuxpl.org/mailman/listinfo/cicq
Questions? Check the FAQ first: http://centericq.de/faq/