New module for KPovModeler

Stephan Kulow coolo at
Thu Jan 9 12:30:06 GMT 2003

Am Donnerstag, 9. Januar 2003 11:20 schrieb David Faure:
> On Thursday 09 January 2003 11:12, Klas Kalass wrote:
> > Am Donnerstag, 9. Januar 2003 11:03 schrieb David Faure:
> > > On Thursday 09 January 2003 10:52, Klas Kalass wrote:
> > > > AFAIR it was also about the small user group that kpovmodeller has. I
> > > > think that the question is how specialized an application in a KDE
> > > > module should be. kdegraphics is released as one package, but I am
> > > > pretty sure that only a very small percentage of people who want
> > > > kdegraphics also want kpovmodeler. The other apps are relevant for
> > > > "normal" desktop use (fax, scan, file viewing,....), but kpovmodeler
> > > > is only relevant for people wanting to make 3D models.
> > >
> > > You're confusing CVS modules and binary packages.
> > > Developers/translators/artists/... see the former, users see the
> > > latter.
> > >
> > > It's currently) up to the distributors to split the source tarballs
> > > (cvs modules) into binary packages.
> >
> > hmmm - KDE does release the package "kdegraphics-3.1.0.tar.bz2"
> > containing all applications from the modules, doesn't it?
> You're right, there are also 'users of source tarballs'. So I think the
> solution is splitting at release time - more work for the release dude :(

Perhaps this isn't the worst option. Put into all subdirs a version.h that
has the version in a standard format. Then we can offer 
kdegraphics-3.2.0.tar.bz2 and for every app an own tar ball in a subdir.
This we could then automate and put it in place already for the daily 

Or we put only in the bigger/specialized apps a file describing it's version
and move these subdirs out of the general tarball. Depending on the number
of apps that would affect this of course means more work for the packagers.

If we have kdegraphics-3.2.0 as mirror of what's in the CVS module, then
people using source tarballs would have to get kghostview, kdvi and have to
fight with quite some dependencies most likely (actually kdegames has already
one lib, kdegraphics has the kviewerpart and kdepim is hopeless to split). 

So I guess splitting out bigger apps out of the main module automaticly is the
better choice. E.g. kbabel would be another candidate. Many translators don't
need the rest of kdesdk and many developers don't translate (sadly :)

Greetings, Stephan

More information about the kde-core-devel mailing list