[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: dpkg-source again broken wrt to 3.0 (quilt)???

On Wed, 18 Jan 2012 22:24:22 +0800
Paul Wise <pabs@debian.org> wrote:

> On Wed, Jan 18, 2012 at 9:13 AM, Jakub Wilk wrote:
> > Wait, are you patching files inside debian/? That won't fly.
> I've personally missed this feature for a package I need to patch
> outside of Debian. 

This is something I'll need to look at again when Emdebian starts
preparing modified cross-built packages to modify the dependency chain
(Emdebian Crush). Currently that's stalled waiting for MultiArch but
the only reliable way I found to do it is to maintain a separate
debian/ directory in a VCS and apply it to the orig.tar.gz. Maintenance
will be a problem but then getting debian/rules to support minor
variants is also plagued with problems of maintenance because most
maintainers will not (have time to / be able to) build the variants,
let alone test them on device.

One example here is qtembedded. I'm currently keeping a debian/
directory based on the version in Squeeze and it could possibly work as
an alternative build inside the Qt debian packages but it's not a short
build and testing it isn't a small task either. (I failed to get a sane
cross-build out of it, so now have to wait 16hrs for a native build.)
We're maintaining this build out-of-tree for now.

It is useful to have the (unchanged) debian/patches/ to include into the
build for the embedded derivative but in other ways, it is just hard to
do well.

> When it was dpkg-source v1 I could just drop in the
> patches/series and everything would work. Now with dpkg-source v3 the
> patches do not apply and months later I'm still wondering what to do
> in this situation.

However, I disagree with you here, Paul. Patches, especially quilt
patches, to debian/ files are NOT maintainable because you still need
to update the patches when a minor debian revision takes place. i.e.
you need the files to which to make the patches so you might as well
make those files use conditionals within the build to enable that
variant and then you at least have the chance to build the full Debian
version with a simple DEB_BUILD_OPTION for sanity reasons.

ifneq (,$(findstring qtembedded,$(DEB_BUILD_OPTIONS)))

I did a LOT of patching to debian/ for the initial development of
Emdebian Crush based on Lenny and the only way to do it is to base on a
suite which is already frozen, otherwise the patches just fail
almost everytime the maintainer does anything to the package. It just
doesn't scale, so it's better to pick a frozen/stable suite and don't
try to keep up with more than a handful of packages.

In future, there will be no patches applied automatically to existing
Debian packages for Emdebian - we'll work out-of-tree and work on some
kind of conditional / derivative buildd support, possibly related to
the idea of partial architectures and existing work on bootstrap builds.




Maintaining a separate tree in VCS is also easy in that various tools
already support it. I used svn-inject with the -o option. Then a
judicious use of meld against apt-get source is enough to add a few
updates for the next build.

Admittedly in the current build, the option is explicitly set for ease
but that's just debug. There are niggles which I'll get around to
filing as bugs once I start doing this seriously again.

What I'd like to see is better support for conditionals in debian/rules
to allow packages like busybox, cairo, curl, openssh and others to be
routinely built with certain optional components turned off or
particular configurations turned on (in the case of busybox) -
possibly only on certain architectures. Yes, those builds may well be
dangerous to install on a regular Debian box (busybox in particular) but
there are still situations where ldap and the like make installation of
standard Debian packages (or packages from Emdebian Grip) completely



Neil Williams

Attachment: pgp9QVchWlDHP.pgp
Description: PGP signature

Reply to: