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

List:       kde-core-devel
Subject:    Re: Tagging kdesupport projects
From:       Sebastian =?utf-8?q?Tr=C3=BCg?= <strueg () mandriva ! com>
Date:       2008-09-02 14:00:46
Message-ID: 200809021600.46979.strueg () mandriva ! com
[Download RAW message or body]

On Monday 01 September 2008 23:26:32 Harri Porten wrote:
> Hello,
>
> On Mon, 1 Sep 2008, Sebastian Trüg wrote:
> >> I have to say that I find the tendency to move hard-requirement
> >> libraries (targetted at KDE mostly) into kdesupport a bit disturbing. It
> >> could have been done with KJS too (its only requirements are libstdc++,
> >> libstdc and pcre) but I found it counter-productive. Instead I favor
> >> development within KDE. Seperate packages for non-KDE use can always be
> >> produced.
> >
> > I don't get the problem. It is so simple: on mondays it is possible that
> > stuff breaks. thus, when it does, simply update kdesupport to trunk and
> > keep on. You need to do the exact same thing with kdelibs. There are no
> > multiple branches you need to choose from. There is trunk for bleeding
> > edge developers and there are the releases in case you are an app
> > developer who "only" needs KDE 4.0 or 4.1.
>
> So for trunk development I get to use Subversion (and update weekly) but
> for KDE 4.1.x development I can download a tar.gz file and compile that?
> And if there's a bugfix release there's a new package to download? Or are
> there appropriate branches I can use? Which ones? How are they named?
> Differently per sub-dir?

It is a NORMALLY released package. Of course there are bugfix releases. They 
are announced like any other package is. I don't get your problems. Check the 
homepage, use the distribution provided packages. You don't have a problem 
with all the other kde dependencies. Why with kdesupport. Stop this useless 
thread!

> > There is absolutely nothing complicated about that. If you
> > can compile kdelibs, you can also compile kdesupport, it is much smaller.
>
> Sounds like something that should be in kdelibs (or the respective module
> requiring the library) then.

If you really want to I can move Soprano out of the kde svn and into my own 
sourceforge one. I really don't care one or the other way except that it will 
take time that I would rather spent on important things (very much like this 
thread does)

> Sorry when I'm not so easily convinced here. I understood kdesupport as a
> convenience thing to house e.g. mimelib. I also appreciated if a developer
> who's library is used in other projects develops the code in KDE's
> repository. But from the perspective of an average KDE developer I fail to
> see the difference between e.g. strigi and libz. These are external
> dependancy that developers and users can be asked to update in reasonable
> intervals - to stable versions. If an up-to-date Linux distribution is not
> carrying this version it's a sign that the requirement might be not so
> reasonable. If the requirement to update appears on a weekly base (based
> on specific demands for KDE code) this is a strong indication that we are
> talking about a de-facto KDE library.

no. kdesupport provides stuff that does not depend on kdelibs but still needs 
to be bleeding edge for trunk. It is really simple.

> If the common opinion is that the order of updates should always be
> kdesuport -> kdelibs -> ... I suggest we rethink our definition of the
> "kdelibs" module. Isn't it our lowest level of library? Or should it be
> named "kdelibs2" with kdesupport being renamed to "kdelibs1"? ;)
>
> Harri.



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