On Mon, Apr 02, 2012 at 10:17:25AM -0400, Joey Hess wrote:
> Adrian Bunk wrote:
> > Severity: serious
>
> Inflated. Bug #634741 probably did not affect many packages.
The workaround for #634741 was always to delete the unwanted dir file
manually in debian/rules.
The number of packages relying on it not being generated in the first
place in the future might be much higher.
> It is up to the indidivual package maintainer to use debhelper
> in a way that produces a good package; there are many ways to use
> debhelper that produce bad packages, and these are, on the whole,
> not RC bugs in debhelper. AKA, bug inflation wastes my time typing this
> paragraph.
You don't have a cut'n'paste template for inflated dependencies? ;-)
See also below.
> > With that the build behaves differently depending on what automake
> > version is installed.
>
> It's not debhelper's job to ensure that packages always build the same
> no matter what versions of build dependencies are installed. Ensuring
> that a sane set of build dependencies are installed is the job of the
> package maintainer.
The problem is that build dependencies like
Build-Depends: debhelper (>= 9.20120311), automake
Build-Depends: debhelper (>= 9.20120311), dh-autoreconf
would then be RC bugs in the packages.
IMHO it's a serious risk that this would be a pattern for many future
RC bugs, and that makes the bug in debhelper RC for me.
If it is OK to have many such future RC bugs then this bug here is
wishlist+wontfix.
> > Please add a "Breaks: automake (<< 1.11.2)" to debhelper to ensure
> > that automake supports AM_UPDATE_INFO_DIR=no.
>
> This would only make backports of debhelper impossible to use, unless
> someone also backported automake.
Considering that a backport of dpkg is already required that shouldn't
be a real issue.
And as soon as one package relies on the AM_UPDATE_INFO_DIR=no it can
anyway not be backported without an updated automake.
> It also appears to be a misuse of Breaks. Automake is not broken by the
> installation of debhelper. A Breaks field would only cause automake to
> be deconfigured, which would not prevent debhelper from using it. The
> correct field, if any, is Conflicts.
The problem only occurs when the package being built has a build
dependency on automake, and that won't be fulfilled with a deconfigured
automake.
> see shy jo
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
