death to kdeaddons, long live extragear!

[Marc Espie]

On Wed, Aug 29, 2007 at 10:15:31PM -0400, Alexander Neundorf wrote:
> 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.

I actually know a bit about packaging, not surprisingly.
First, rpm and deb only cover a large part of linux distributions, but not
everything linux (all BSD use something different for starters). Second,
packaging needs very little support from make systems. The most important
feature, in fact, is to be able to separate *packaging* from installation,
namely, you just want correct DESTDIR support, that works as far as it
can *without installing stuff on the actual live system*, but putting 
everything in a separate area.

The actual packaging problem is mostly impossible to automate simply. It
involves tracking dependencies, finding update paths that work (if possible
minimizing the amount of scripting that always fucks up), and in many cases,
identifying issues with less needed dependencies.

Once you figure out that dev teams build binary packages, and that users
install them, some things become clear (more or less): as a packager, you
make editorial choices, such as requesting some dependencies explicitly,
or building packages with less often needed stuff.

For instance, in KDE3 on OpenBSD, we've been bundling the samba stuff as
a separate package (which fortunately works very well, since this is
runtime stuff), and likewise for cups. The packages are always built with
samba and cups configured, just the parts that require samba and cups are
packaged separately.

This is the kind of stuff that's really needed. cpack won't help there.