[Pkg-kde-extras] Re: KDE packages

[Achim Bohnet]

On Thursday, 14. December 2006 12:58, Ana Guerrero wrote:
> 
> On Thu, Dec 14, 2006 at 11:39:07AM +0000, Marc 'HE' Brockschmidt wrote:
> > > * libkexif (0.2.5-2)
> > > Yes, this is a new upstream version, but it is a bugfix release, and it is
> > > necessary in order to avoid a lot of problems with digikam 0.8.2 (since
> > > digikam will be back to this version).
> > 
> > debian/patches/98_buildprep.diff      |53096 +++++++++++++++++++++++++---------
> > 
> > You're kidding, right? Please explain to me why 2/3 of the build system
> > need to be replaced?

For _every_ KDE app one can bootstrap the build system with

	make -f Makefile.cvs

Depending with version of auto* tools that were used when upstream
created the released tarbal, changes created by a
rerun can vary from small to huge in size.

make -f Makefile.cvs is IMHO also a very safe change, because it
run hundreds of times every day by KDE developers and people building
svn snapshots version of apps.   When one looks at the buildprep.diff
one can also see that the it's always the same change that is just
applied to all Makefile.in's.

Note: KDE does not use plain auto* magic in it's build system,
but add even another level on top of it!

Technically, when a *.am or *.in.in file is touched, we use
a script that runs:

	o applies debian patches
	o run make -f Makefile.cvs to regenerate the build system.
	o collect difference in debian patches/98_buildprep.
	o undo the holecrap so build are idempotent again

When debian patches touch files of the buildsystem, KDEautomaticly
regenerates the build system during run time, which needs additional
build depends.  Additionally patches may fail for a 2nd build
because the they conflicts with regenerated file(s).

For all this and some more reason the use the above mentioned script,
so the rebuild is done once and not every build again and again.


Last but not least, the big patches are the conequense of
debian-release asking to relibtoolize pkgs to avoid unnecessary
shared lib dependencies that make testing migration a nightmare.

To quote from 0.2.2-3 changelog

    Result: libkexif1 now depends on 6 instead of 25 packages

I hope relibtoolizations are still welcome. :)


> > 
> > > * kwlan (already requested by Mark Purcell)
> > 
> > No. The diff is unreadable, littered with tons of autofoo changes and
> > quite a lot code changes.

FWIW: That's another way of doing it.  The libkexif diff just shows
one huge 98_buildpref.diff instead of 'unreadable, littered with tons of
autofoo changes'.

I hope what shows you the beautity of an even huge 98_buildprep.diff.

Achim
> > 
> > > * ksynaptics (already requested by Mark Purcell and Fathi Boudra)
> > > http://bjorn.haxx.se/debian/testing.pl?package=ksynaptics
> > > This package is not required for build on s390 as documented:
> > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=383698
> > 
> > Then the old binary needs to be removed. I have unblocked the package,
> > though.
> >
> 
> Can someone answer to Marc about this.
> 
> _______________________________________________
> pkg-kde-extras mailing list
> pkg-kde-extras at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-extras
> 
> 

-- 
  To me vi is Zen.  To use vi is to practice zen. Every command is
  a koan. Profound to the user, unintelligible to the uninitiated.
  You discover truth everytime you use it.
                                      -- reddy at lion.austin.ibm.com