[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: glib dependency
From:       Marc Espie <espie () quatramaran ! ens ! fr>
Date:       2003-03-29 22:27:35
[Download RAW message or body]

In article <3E778CEB.9050101@usm.edu.ec> you write:
>No.  I'm not assuming that every distribution is LSB compliant.  I'm 
>stating that his linux distribution isn't LSB compliant.  I know there 
>are lots of reasons not to have RPM and use the Debian package system, 
>but the standard says RPM v3.  The whole idea of the LSB is to have 
>applications respect it and adopt it.

LSB ? Idea ? Applications ? what does it have to do with *non-linux*
distributions ??? Some of us use other OSes, and are very happy to have
kde, and would rather NOT get more cruft in than already is... glib being
such cruft.


>My point was that you can currently count on the majority of Linux 
>distributions to respect the LSB, and hence find PAM in their Linux 
>distributions.  So for the majority of Linux distributions there's PAM. 
> And that code is automatically correct for the majority of Linux 
>distributions.  Yes, we're both right that the author of that particular 
>snippet of code should have tested for PAM directly.  Much better idea 
>than testing for Linux or BSD.

And my point would be that not all the world is Linux...


>This all very off-topic.  Returning to the other off-topic topic, I see 
>that most apps currently require glib, and arts even statically includes 
>a copy of it.  Why statically including it when it could be a dynamic 
>library, for the benefit of  everyone?
>
Maybe I should look closer, but I don't see glib in arts 1.1...
>The question I'm forced to ask is: why are the arts people using GLib? 
> There must be a reason.  Let's identify the reason, and either provide 
>a solution for them, or take the leap and make GLib a KDE (or ARTS) 
>dependency.  If they can remove the GLib dependency without decreasing 
>the quality of the code, let them remove it.  If they can't, let's 
>either make a subset of GLib and dynamically include it, or let's 
>include the whole GLib thing, and finish the discussion.  

In fact, as far as I know, only the `gmcop' stuff in arts uses glib2,
and it's quite easy to package it separately, and offer  it as the only
part that requires glib2... the rest of kde does not require glib2... 
thankfully.
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]