Re: The wider implications of debhelper/dbus breakage
On Wed, 22 Jul 2009, Cyril Brulebois wrote:
> Raphael Hertzog <email@example.com> (17/07/2009):
> > At least dpkg-dev has one and it's run at build-time.
> I thought the goal of dpkg-dev was to actually build other packages. I
> don't know how dpkg-dev developers see this, but maybe having a few
> packages rebuilt using the new dpkg-dev package would help spotting
Well, I always run the git version on my machine. But maintaining dpkg-dev
is enough of a job that I don't maintain many other packages... so I
don't build many other packages except for QA work or similar (like
investigation build failures with the new source format).
> I dunno, but especially eglibc and other important packages
> would be quite good candidates.
Well, multiple hours compilation don't buy us much testing of dpkg-dev.
That said the bigger packages are also those that make usage of the
> I guess that a loop for getting the
> source packages, pushing them through sbuild once with the old dpkg-dev
> package and once with the new dpkg-dev packages, then debdiffing (and
> whatever interesting diff tests might come to mind) would help and
> wouldn't be very hard to implement.
Are you interested in writing it? :-) I don't see anything that needs to
be specific for each tool. Starting with a new sbuild option to
auto-install a new .deb in the chroot (and restore the official one
provided by apt) would be half the job.
Deciding what difference is tolerated is the second (more annoying) half
of the job.