Re: Help wanted: simple tasks

On Wed, Feb 21, 2007 at 06:50:29PM -0500, Mark Neill wrote:
> On Thu, 22 Feb 2007, Andreas Niederl wrote:
> >Well, it shouldn't be that much of a problem. You could only support
> >certain versions of the used libraries, so the users have to check their
> >problems also with those before leaving the debugging work to the
> >developers.
> >Fixing libraries with an active and cooperative upstream may be more
> >efficient than trying to solve things alone IMHO.
> >Of course, if a lib is unmaintained or has a very lazy maintainer,
> >inclusion is still an option.
> 
> 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.

> 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.

> 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.

This is of course at each maintainer discretion, however I felt the
need to point out the drawbacks I see on bundled libraries. As always,
YMMV.


		Damián Viano(Des).
_______________________________________________
Cicq mailing list
[email protected]
http://mailman.linuxpl.org/mailman/listinfo/cicq
Questions? Check the FAQ first: http://centericq.de/faq/