death to kdeaddons, long live extragear!

[Alexander Neundorf]

On Wednesday 29 August 2007 16:25, Aaron J. Seigo wrote:
> On Wednesday 29 August 2007, koos vriezen wrote:
> > 2007/8/29, Aaron J. Seigo <aseigo at kde.org>:
> > > hi all...
> > >
> > > i'd like to propose that we kill kdeaddons for kde4 and instead move
> > > everything worth keeping to extragear/.
> >
> > Btw, what bothered me in extra gear3 is sharing the configure stuff w/
> > other apps in the same usage category. Together with the fact that
> > even Debian packages eg. konq-plugins in one big package, whereas it
> > otherwise does a pretty good job of splitting apps, meaning that if I
> > want uachanger a get lots of never-will-use stuff for free, I like to
> > plea for a complete separation of each tool.
>
> it's usually a few lines to add to a given CMakeLists.txt file to make
> something stand alone rather than conglomerated. it probably makes sense to
> provide some scripts for packagers to make this job easy; perhaps even a
> little (gui? commandline? both?) tool that lets them select a strategy
> (e.g. "one package for each thing", "one package for each module", "just
> these 5 things", etc) and which modifies the CMakeLists.txt files
> appropriately.
>
> this wouldn't be hard to do for extragear, really; the big trick is when
> there is an all-in-one build for things (which imo is better for most
> source users, better for developers and nicer for the "package everything"
> people), then different apps/plugins will share checks. e.g. the plasma
> applets that require OpenGL all rely on that check being done in the base
> module. so the FindPlasma call will need to be propagated to each plasma
> applet/engine/etc if a "one package for each thing" or a "just these five
> things" strategy is chosen.
>
> in any case, despite that the above may sound semi-coherent (hopefully,
> anyways ;), i'm really not the best person by far to come up with an
> implementation plan for this. there are others with far more packaging
> experience than my meager sum around who probably have deep insight here.
> not to mention people like Alex-the-cmake-god.

Hmm, ok, I also don't know that much about packaging, but I'd like to mention 
that cpack which comes with cmake has improved a lot in cvs, which will 
become cmake 2.6 later this year.
cpack can now also create debian and RPM packages.
Projects which want to create packages with cpack need to set a bunch of 
variables and then include CPack. While this makes things ugly if you do this 
directly in the cmake files, you can of course split this into a separate 
file: http://www.cmake.org/Wiki/CMake#CPack

If cpack is currently (as in cmake cvs) not good enough for us, I'd really 
like to have either a list of features we need to use it for kde packaging or 
even better feature requests/bug reports in the cmake bug tracker, component 
cpack.

E.g. it would make creating user/development packages easy (if we extend our 
install commands) and we would have an all-in-one solution.

Bye
Alex