[Pkg-kde-talk] KDE 3.4 package underway

[Christopher Martin]

--nextPart1617725.39j9eIVT2P
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On March 1, 2005 19:13, Pierre Habouzit wrote:
> Le Mar 1 Mars 2005 18:33, Christopher Martin a =E9crit :
> > 1) Have two unpacked source directories: foo-1.2.3, foo-1.2.3.orig.
> > One contains a debian subdirectory, one does not.
> >
> > 2) Run fakeroot debian/rules buildprep in the debianized source
> > directory. This runs make -f admin/Makefile.common dist, cleans up,
> > and handles 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.diff.
>
> 2/3 things :
>
> IIUC the 4) it's a pragma that helps simple patchsys to discover the
> patchlevel it has to use  ... but AFAIK, simple patchsys tries -p0 -p1
> and -p2 alone, so it should work out from the box.

The RC1 tarballs dato made available have Makefile.in files provided. I=20
don't know if dato created them, or whether he just obtained them this way.=
=20
Anyway, we patch them, and everything is fine. If, however, you take a CVS=
=20
checkout, then these files are generated only when make -f=20
admin/Makefile.common dist is run. The 99_buildprep.diff then contains the=
=20
complete Makefile.in files. The patchsys tries -p0 first, and this actually=
=20
succeeds in creating these files, but in a subdirectory of the build=20
directory, e.g. kdelibs-3.4.0/kdelibs-3.4.0/Makefile.in. This is when we=20
have to force -p1.

Alternatively, when making a CVS checkout, you could run make -f=20
admin/Makefile.common dist prior to the generation of the .orig.tar.gz, but=
=20
I don't really see why one would bother, since this would mix=20
Debian-generated (and Debian-specific, since not everyone uses the same=20
autotools) stuff with KDE CVS.

> moreover, to have the same thing as what you do to build your
> 99.....patch, you can build the package, and then extract from
> the .diff.gz the parts that are not related to debian/ files ;)
>
> but honestly, I don't really see the point in making it a patch in
> debian/patches since is won't *really* clean the .diff.gz. It will only
> make it a bit worse : it will be the same as before, with 2 lines
> added, and a big column of '+' ;)

I think it's nice to have all the build-system stuff in a nice, separate=20
patch. It can then be removed easily (just unpatch), re-applied, etc. It's=
=20
more a matter of "style" and of how you like to work than an important=20
technical decision, though as a group we should probably try to be=20
consistent. Comments from anyone and everyone?

Cheers,
Christopher

--nextPart1617725.39j9eIVT2P
Content-Type: application/pgp-signature

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

iD8DBQBCJhw+U+gWW+vtsysRAo5zAJ9H3dtyXvcgLzfG/2O3A09zgNn4/gCeJBUm
eGsg6CyRC5TmC/2I++yCv28=
=Gxce
-----END PGP SIGNATURE-----

--nextPart1617725.39j9eIVT2P--