[Pkg-kde-talk] KDE 3.4 package underway

Christopher Martin christopher.martin@utoronto.ca
Tue, 1 Mar 2005 12:33:20 -0500


--nextPart2944326.8YQxdveG7W
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hello,

I'm back now, and see that many people are doing lots of great work on the=
=20
3.4 packages. I'd like to comment on the TODO:

> arts:
>   - not merged changes from Christopher
>     + manpages deletion (plus removing docbook-to-man from B-D)

I deleted the manpages that were just placeholders. No manpage is better=20
than a fake one, since then the problem is less hidden. Also, fake pages=20
tend to really annoy users. This is bug #292084.

>   + the removal of "sharutils, texinfo, xlibs-static-pic" in B-D

sharutils I removed until we figured out a uu patch method, though we're no=
t=20
likely to need one very often. xlibs-static-pic/texinfo was aggressive=20
"let's see what and how things break" pruning.

> kdelibs:
>=20
>  - not merged changes from Christopher
>    + manpages removal <-- I agree, but I don't understand why he has
>       removed all *.sgml files and left only the generated *.1 ones

I was lazy when putting together the initial packages :) Anyway, as with=20
arts, I'd like to remove all the dummy pages.

>   + build-dependencies:
>      - remove libdb4.2-dev, libldap2-dev, libpam0g-dev, libxrender-dev

I wasn't sure whether db, ldap, and pam are needed for kdelibs nowadays.=20
Nothing depends on them, and no obvious configure checks fail without them=
=20
(IIRC). As for xrender, libqt3-mt-dev pulls that in.

>     - remove libfam-dev in favour of libgamin-dev --> works?

Works well here, anyway. A nice bonus is that gamin supports inotify, so=20
we'll gain support for that when it reaches the kernel.

>     - remove docbook-to-man, sharutils, texinfo, xlibmesa-glu-dev

Same as above, with xlibmesa-glu-dev pulled in by Qt.

>     + remove kdelibs-bin depending on python

My policy was to yank anything I didn't see was needed, then watch in case=
=20
anything broke. Do we really need this? Anyone?

>     + use wildcards in *.install =3D> calc said it gave problems
>        sometimes (IIRC)

Ah, OK. I'd be interesting in learning why/where these problems occurred.

>    - the dependencies of kdelibs4-dev are not synced with
>       build-dependencies

I'd started tinkering with this in my packaging, though this hasn't been=20
merged yet (and needs more attention anyway).

=2D--

I'd also like to explain how I'd been building my preliminary KDE 3.4=20
packages, and why I think it's a nice way to do things:

1) Have two unpacked source directories: foo-1.2.3, foo-1.2.3.orig. One=20
contains a debian subdirectory, one does not.

2) Run fakeroot debian/rules buildprep in the debianized source directory.=
=20
This runs make -f admin/Makefile.common dist, cleans up, and handles=20
patching.

3) Move the debian dir out of the source directory.

3) diff -Nrua foo-1.2.3.orig foo-1.2.3 > 99_buildprep.diff

4) Add "#DPATCHLEVEL=3D1" (no quotes) as the first line of 99_buildprep.dif=
f.

5) Move 99_buildprep.diff to debian/patches, rm -rf foo-1.2.3, and move the=
=20
debian directory into foo-1.2.3.orig, which is then renamed foo-1.2.3.

6) cd foo-1.2.3, build package.

This way, we keep the .diff.gz nice and clean, with build stuff contained i=
n=20
a patch only. Also, automake/conf are run only once, by the packager,=20
rather than at every build time, which is an extremely bad idea, because it=
=20
reduces reproducibility (that's also why I took out the=20
debian/stamp-cvs-make stuff from kde.mk - best not to encourage the=20
practice).

As for KDE 3.3 - should we upload kdemultimedia 3.3.2, now that 3.3.1 is in=
=20
Sarge? kdenetwork could be also use another upload (with the kopete/xmms=20
fix), unless anyone objects.

Cheers,
Christopher

--nextPart2944326.8YQxdveG7W
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Signed by Christopher Martin <chrsmrtn@freeshell.org>

iD8DBQBCJKdsU+gWW+vtsysRAhznAJ9kBMuT5Ym+owvKWzKiUysX+2ZgGwCgp3Me
tGoljl0211yWPTTa5+D37vY=
=WiC4
-----END PGP SIGNATURE-----

--nextPart2944326.8YQxdveG7W--