2 Sep 2008 16:00
Re: Tagging kdesupport projects
Sebastian Trüg <strueg <at> mandriva.com>
2008-09-02 14:00:46 GMT
2008-09-02 14:00:46 GMT
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.