kde teams and/or maintainer of everything

Carlos Leonhard Woelz carloswoelz at imap-mail.com
Thu Sep 9 02:42:26 CEST 2004


On Wednesday 08 September 2004 19:51, J. Preiss wrote:
> Am Mittwoch, 8. September 2004 23:46 schrieb Aaron Seigo:
> > On September 8, 2004 9:32, J. Preiss wrote:
> > > I am wondering how KDE itself works... is there someone who cares for
> > > all packages, someone "above" the single packages?
> >
> > we have the "Release Dude" who manages the release schedule and packs up
> > the tarballs.
>
> Ok, but he's (sorry Sandra/Stefanie/all the others ;-)...yes, I read the
> pages!)/she's responsible for taring or releasing. Nothing else, right?

His name is Stephan Coolow, and he is responsible for a lot of stuff. The 
Release Dude cares for the quality of the stuff he delivers as well as the 
delivery.

> > > And who is responsible for each package with its projects inside?
> >
> > the project maintainers, of which there are many. nearly as many as there
> > are applications and packages =)
>
> No, I really mean one step above. Of course there are package maintainers
> and sure project maintainers...
<snip crazy theory>
There are no "package maintainers", only application maintainers.
You can get the maintainers name in the file "MAINTAINERS", usually in each 
module root folder.

> > > I'm asking because now that I posted my kde builder to kde-apps and
> > > some people found it ok, it would be great to have some meta
> > > information in the cvs tree. I dont know how or what this meta info
> > > could be, but it sure would be useful for the other builders like
> > > konstruct too (?).
> >
> > what sort of meta info? you mention dependencies, but what sort of info
> > specifically?
>
> Shortly explained: something like rpm does, but within cvs as files. I dont
> (yet) know all depencies of every kde-package. I know there is a package
> kdevelop. I think that its translations are inside of i18n. Maybe there is
> some documentation inside, but also it could be inside a package called
> docs. When I do a make install of i18n with only kdevelop downloaded from
> cvs, every translation in every language will be installed. I did not have
> a look into the kdearts stuff, but I assume it will be the same there. Or
> using the kdeextragear, surely kdeextragear-lib1 is needed... well... isn't
> it???? If I had some kind of depency information, I may could resolve them.
> Before project [x] is compiled, library [a] is needed. When I install
> project [b], translation [f] is needed, but only in selected languages.
> Something like that...
> I dont know if this is possible at all. Its just a question.

No, you have to get all the dependencies by hand. The rmp packagers get this 
information by hand as well.

> > > The other problem is an uninstall. With qbuildkde you can deselect
> > > packages, so they are neither compiled nor installed - ok. But if you
> > > just want to have a look at a tool and it doesnt fit your needs, you
> > > have a problem. Is there a package where make uninstall is used? Or
> > > would it be a problem to add this option?
> >
> > `make uninstall` doesn't work for you? you could also look into using
> > checkinstall .....

Unistalling individual application is not simple and very messy. Some 
applications need common libraries, and there is nothing automatic you can do 
about it. checkinstall may be a solution, as aaron pointed out.

That is why I recommend the use a dedicated user to install KDE, instead of 
messing with the root folders. If something goes wrong, you can nuke the
user installation, but not the root folders.

> The question was not if make uninstall works for me nor if I'd like to use
> checkinstall (heard and read about it, never used before). Exactly the
> question is, if there is at least one project which understoods
> uninstalling, or if it is useless to look for such projects. If there is no
> chance that the uninstall process will be understood, I must use
> checkinstall - what would be another depency of my project. I dont think
> there are that many using it, so what advantage would it bring? But if,
> lets say, 5 projects are using uninstall, the chance will grow that all
> others could use it to. To get back to the old wise man: someone may could
> tell them, that it would be better for the whole kde process to understand
> make uninstall.

make unistall works for the whole module, not for individual apps.

> And these problems araise from the following: its so easy to
> compile/install the complete kdeextragear-tree. With the configure option,
> its even easy to c/i one package from it. But once you have installed the
> complete tree, how do you remove kate (or whatelse)? Now assuming a newbie,
> compiling and installing the complete KDE tree, just to see whats in it -
> he will never be able to get a small system. And I think thats a pity.

It is crazy to compile the whole kdeextragear-tree. In kde-extragear, you have 
to treat each folder as if it were a separate module. The building guide 
shows how to do it.

Cheers,

Carlos Woelz


More information about the kde-quality mailing list