Tagging kdesupport projects

[Harri Porten]

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?

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

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.

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.