Moving kfilereplace to kdeutils

[Lauri Watts]

On Friday 12 November 2004 21:05, Knut Morten Johansson wrote:
> On Friday 12 November 2004 Michael Nottebrock wrote:
> >Move Cervisia out of KDE and into kdeextragear. If it looks like packagers
> >will have to package it standalone anyway to be able to resolve the
> >dependencies Quanta and KDevelop have on it properly, there's no point in
> >dragging it along with kdesdk. Thinking about it, most of the recent
> >additions to kdesdk really would lead a better life in KEG, kompare,
> >umbrello, kcachegrind...
>
> Most packagers builds standalone packages for all of those anyway so I
> whats your point. The clue with having different modules are to group
> programs which makes sens to keep together, ether for dependency issues or
> area of usage.

Michael is a packager.  Not all of us build standalone packages, and doing so 
is rather a pain when the system is not set up for it. 

I expect at least the other BSD's and Gentoo (and maybe others, I don't know 
for instance, how Fink is packaged, or Solaris) to be in a similar boat when 
it comes to inter-module dependencies.  Certainly everyone compiling from 
source is affected by these matters anyway.  What happens when something in 
kdemultimedia decides to have a compile dependency on something in kdeutils, 
and something else in kdeutils has a dependency on kdeadmin?  It's not out of 
the question, and in fact, it's happened before, if only accidentally.  It's 
the same situation as the recent kdm build problem in kdebase, but on a much 
more difficult scale.

If the other packagers are making separate packages for everything anyway, 
they don't need to care where things actually live in CVS to satisfy their 
dependencies.  We do care, and we're asking to please consider us when 
deciding where to put things.

The KDE dependency tree has traditionally been very flat:

Compile time dependencies are within the same module, or provided by kdelibs
Most of the runtime dependencies are clearly noted in configure output, or 
provided by kdebase
kdeaddons contains all the things that have other-module dependencies (with 
the exception of kdeartwork, and kdevelop which depends on half the planet 
anyway.)
Other apps that have multi-module dependencies, are currently provided as 
standalone tarballs (either as third party applications, or in kdeextragear)

Very easy for CVS, and for packaging: build arts, kdelibs and kdebase in that 
order, build kdeaddons last, and in between, build all the rest in any order 
you like, and skip the ones you don't want.

All we're asking is that this arrangement is kept to.  

If there are in fact compile time dependencies, why not put it in an 
extragear, where a tarball can be released any time the maintainers feel 
like, even if that coincides with the KDE release schedule?

Regards,
-- 
Lauri Watts
KDE Documentation: http://docs.kde.org
KDE on FreeBSD: http://freebsd.kde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20041113/7771cdbd/attachment.sig>