Moving kfilereplace to kdeutils
lauri at kde.org
Sat Nov 13 00:24:12 GMT 2004
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
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?
KDE Documentation: http://docs.kde.org
KDE on FreeBSD: http://freebsd.kde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: not available
More information about the kde-core-devel