Bug#666901: debhelper needs a "Breaks: automake (

April 02nd, 2012 - 07:20 am ET by Adrian Bunk | Report spam
Package: debhelper
Version: 9.20120322
Severity: serious

<-- snip -->

debhelper (9.20120311) unstable; urgency=low

* dh_auto_install: Set AM_UPDATE_INFO_DIR=no to avoid automake
generating an info dir file. Closes: #634741


<-- snip -->


With that the build behaves differently depending on what automake
version is installed.

An example is if a package for the official Debian backports
gets built with latest debhelper but automake from stable, and
packages from the official Debian backports might suddenly start
shipping info dir files.

Please add a "Breaks: automake (<< 1.11.2)" to debhelper to ensure
that automake supports AM_UPDATE_INFO_DIR=no.



To UNSUBSCRIBE, email to debian-bugs-rc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
email Follow the discussionReplies 2 repliesReplies Make a reply

Similar topics

Replies

#1 Joey Hess
April 02nd, 2012 - 10:30 am ET | Report spam
Adrian Bunk wrote:
Severity: serious



Inflated. Bug #634741 probably did not affect many packages.
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.

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.

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.

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.

see shy jo



To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Replies Reply to this message
#2 Adrian Bunk
April 02nd, 2012 - 11:00 am ET | Report spam
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
with a subject of "unsubscribe". Trouble? Contact
email Follow the discussion Replies Reply to this message
Help Create a new topicReplies Make a reply
Search Make your own search