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

List:       kde-devel
Subject:    Re: libkonq
From:       David Faure <david () mandrakesoft ! com>
Date:       2000-04-06 12:48:41
[Download RAW message or body]

On Thu, Apr 06, 2000 at 02:41:06PM +0200, Harri Porten wrote:
> David Faure wrote:
> > 
> > On Thu, Apr 06, 2000 at 01:50:58PM +0200, Harri Porten wrote:
> > 
> > > The "Every lib that's used by at least 2 apps has to be moved into
> > > kdelibs" way of thinking is not really practicable in the long run. RPMs
> > > could surely deal with dependencies on seperate libs very well but we
> > > are not the distributor ...
> > 
> > which is why I think that the distributors should package KDE by splitting
> > the CVS modules. Even kdelibs. The RPMS I did for Mandrake split kdelibs-sound
> > out of kdelibs, which is IMHO a necessary good start. The same could
> 
> I didn't know that. Nice move (pun intented).

Hmm, where's the pun ? ;-)

> > be done with most packages, making it easier for users concerned with
> > disk space, for distributors that re-package one package (for update or fixes),
> > and we would make more noise on freshmeat and other app-watching sites ;-))
> 
> Right. We already know that certain libs will have a constant process of
> improvements in the future.

I was talking of the case where the _distributor_ wants to change
something in a package (customisation, bugfix, etc.), but yes,
there is also the case where we release updates...

> > My suggestion (not new... but didn't get any answer previously) would
> > be that we put a document together that says how we want the modules
> > to be split at packaging time - so that we avoid the problem of each
> > distributor/packager doing it his own way (and us having no idea about the
> > packages existing out there). I volunteer to help in this area, but for
> > this we need to decide to go this way.
> 
> Hmmm. Why just document that process ? A ready-made script (based on
> cvs2pack) would be even nicer. We could even run that script each night
> ourselves and upload the splitted versions (once we have all that
> computing power from SourceForge;)

That's a very very good idea !
Yes, definitely the way to go !

> > PS: the relation with this is that kwrite, kdesu and libkonq could
> > be a kdelibs-utils (since they're not needed for, say, koffice, kdemultimedia,
> > kdegraphics, etc.) but only for some kdebase apps, kdevelop and some others.
> > Sure there could also be one package for each of those libs, but then
> > it's a bit too much ;-)
> 
> How much pain will the i18n messages cause ? /me already sees coolo
> banging his head on the table.

Currently it's one package per language, right ?
Why would a different split of the programs' packages make any difference ?
Or was the plan to split kde-i18n-<lang> into smaller packages
(one per CVS module) ?

-- 
David FAURE
david@mandrakesoft.com, faure@kde.org
http://home.clara.net/faure/
KDE, Making The Future of Computing Available Today

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