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

Re: Generated changes and patch systems

On Sun, 2008-05-25 at 08:40 -0700, Russ Allbery wrote:
> Neil Williams <codehelp@debian.org> writes:
> > On Sun, 2008-05-25 at 13:19 +0100, Mark Brown wrote:
> >> If you run autotools at build time you should also ensure that the
> >> changes which autotools makes are reverted in the clean target.  This
> >> means that your diff doesn't get cluttered with automatically generated
> >> things and ensures that repeated builds of the package produce the same
> >> diff.gz.
> > I haven't seen any other packages doing that - is there an example
> > involving aclocal.m4 somewhere?
> Lots of other packages do this -- one of mine off the top of my head is
> xml-security-c.

Nope. No mention of aclocal.m4 in debian/rules for that package,
just /usr/share/misc/config.guess and config.sub.

I need to patch configure and configure.ac in this package, that means
that aclocal.m4 is constantly being changed and reverted. It shouldn't
matter - it really should not.

I see no purpose in lintian (or dpkg come to that) testing for changes
in aclocal.m4 - IMHO it should simply be exempt from this check. No
distro can risk patching aclocal.m4 - by it's nature it is transient and
volatile and subject to large changes entirely at the mercy of external
factors. Any build system that tries is simply going to break
constantly, AFAICT.

No matter how I wrap the cp foo foo.safe mv foo.safe foo in
debian/rules, the first build can be OK but all subsequent builds end up
with aclocal.m4 in the .diff.gz. Besides, replacing aclocal.m4 after it
has just been updated by ./configure is not a good idea to me.

> > I really don't want to do all that for the tmpl/* files as well - I
> > don't see the need, copying dozens of files into foo.safe or
> > foo.upstream and then moving them back?
> Just delete them then.

??? That simply does not work. The problem is that running gtk-doc not
only requires tmpl/*.sgml files to exist but it *then modifies them*!
Even though I don't install these files into the package, I cannot
delete them and I cannot move them out of the way or the documentation
is not updated. Again, first build can be OK, second build generates a
dozen spurious warnings (because the files are modified after
the .diff.gz is created but cannot be reliably reverted before the next

I don't see that I should provide out-dated documentation (by dropping
--enable-gtk-doc) just because it suits lintian - neither can I patch
the updates because the updates themselves are generated by a third
party tool so I can neither control the changes made nor maintain
"clean" patches. I suspect the issue arises because upstream happen to
prepare the release tarballs on Ubuntu or Fedora where the tool version
differs. The precise reason is inconsequential - the problem is that
Debian should not need to care about these modifications. It's taking
'divergence' one stage too far.

With these gtk-doc files, it's not so much that the tmpl/*.sgml files
are generated but that a tool essential to the build modifies them in a
way that cannot be patched because the results of the patches are
variable according to that third party tool. The changes then affect the
files that are packaged. Some of these are formatting changes -
whitespace changes, extra lines, comment changes. Other changes cause
sections or entire pages to migrate within the final files. The "sense"
of the docs doesn't appear to change, just the internal structure - as
determined by the differing versions of the tools used.

The CDBS build doesn't do anything different - it's just that lintian
doesn't produces any warnings for this check in CDBS packages, ever.

> The point is to not put mechanically generated changes in the diff, since
> it makes it much harder to review what the maintainer has actually done.

I don't see how it can be prevented. Take a look at the current .diff.gz
for libgpewidget 0.115-5 in the archive.

> I think most people take the approach of just deleting such files in the
> clean target, which will exclude their changes from the diff.

Sorry, it is not as simple as that - the package simply won't build if
tmpl/*.sgml are removed, no rule to make tmpl/*.sgml.

The tmpl/*.sgml files cannot be cleaned and removing aclocal.m4 is
simply pointless (and creates an even larger .diff.gz).

I still don't see what problem this test is trying to solve - AFAICT the
problem didn't exist in the first place and all this extra work appears

I still think patch-system-but-direct-changes-in-diff should be
downgraded to info only, if kept at all.

I fail to see what I'm doing wrong - or even why it matters to lintian.

We risk swapping a minor problem that only occurs when the maintainer
upgrades from one version to another (and which could be fixed by
dpkg-source ignoring changes to generated files in the .diff.gz or not
applying generated changes that do exist in the .diff.gz) for a major
FTBFS error every time some random third party package is updated by
erroneously patching files that contain generated changes outside the
control of the maintainer.

dpkg already detects whether files have been deleted or modified and
whether those changes can be ignored.

It is impossible to maintain clean patches if those patches must include
generated changes.

A possible solution is to invert this lintian check and say that if a
patch system is in use, dpkg-source refuses to unpack/apply anything
from the .diff.gz that is not in the debian/ directory.

make distclean is fine for compiled object files and .libs stuff but
sometimes it just isn't enough - but equally, I don't see that returning
to some mystical pristine source is valid either.


Neil Williams

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: