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

Bug#640874: leave: debian/rules is not a Makefile



Josip Rodin <joy@debbugs.entuzijast.net> writes:

> It was just an arbitrary conversion of a single "is" to "must be" (in an
> unrelated let's-use-consistent-RFC-like-wording drive) that went
> unchecked.

I wanted to mention here that this didn't just suddenly happen as a result
of the existing Policy wording without any further discussion.  There were
several discussions over a few months about this particular Lintian tag,
particularly since it kept coming up in the build-arch discussion, and
there was some consensus on debian-devel before it was added to the
ftp-master reject list.  Part of that discussion was specifically around
whether debian/rules should be viewed as an abstract API or whether the
fact that it's a makefile is an exposed part of the API, and there was at
least one advocate of having it instead be an abstract API.  My read on
the discussion was that the consensus went the other way.

I agree that this was not primarily a technical decision.  Rather, it was
a decision around unity of practice aiming towards simplifying our
packaging methods (which in the past have been divergent to the degree
that it's caused some problems).  We don't want to eliminate diversity
that people find helpful to get their work done or that's a widespread
difference of taste among packagers, such as the dh vs. CDBS discussion.
But no one seemed to be using a non-makefile debian/rules to that purpose;
leave was the only package that didn't have a makefile debian/rules, and
even all your other packages were using a makefile, so it didn't seem to
be a decision on your part to use a mechanism that you found generally
better.

(I don't recall if anyone tried to loop you into that discussion; if that
didn't happen, that was a flaw in that discussion process to be sure.)

The conclusion at the time, at least by my reading of the discussion, was
that this was a bit of flexibility that we didn't need and therefore
probably should eliminate in the name of simplifying the possible
implementation choices, rather than changing the Policy wording to allow
it.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>



Reply to: