Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Bug#553420: debian-policy: Please clarify what is the interface for building binary packages.

0 views
Skip to first unread message

Charles Plessy

unread,
Oct 31, 2009, 12:50:02 AM10/31/09
to
Package: debian-policy
Version: 3.8.3.0
Severity: normal

Dear Policy delegates,

there is currently a discussion on debian...@lists.debian.org with a strong
disagreement on what the Policy specifies for building binary packages, and
what it should specify.

http://lists.debian.org/msgid-search/4AE85D08...@e-tobi.net
(I can prepare a summary if there is interest for this).

In a first step, I think that it would be very helpful to clarify what is the
build interface as of Policy 3.8.3. Currently the Policy specifies what the
debian/rules file is, gives a special role to dpkg-buildpackage, and the build
interface is extrapolated with conflicting interpretation among the developers.

In a second step, I propose to go forward and open the possibility of an
evolution of the constraints on the format of the debian/rules file, according
to the consensus on what the build interface should be (which can be different
from what it is as of version 3.8.3). This part is not independant from the
discussion whether debian/rules should be callable interactively with no
special environment variable set, or if dpkg-buildpackage should be the
canonical tool for this usage.

Have a nice week-end,

--
Charles Plessy,
Tsurumi, Kanagawa, Japan.

--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Russ Allbery

unread,
Oct 31, 2009, 7:39:29 PM10/31/09
to
Charles Plessy <ple...@debian.org> writes:

> The proposed patch puts additional constraints on the packages, that
> would make more difficult refactor later the Policy towards make a
> clearer abstraction of the build interface (which I think is desirable),

I don't believe this is desirable at all, and therefore oppose this
proposal. There is such a thing as too much freedom of choice. Debian
already has a very complex package build system compared to RPM-based
Linux distributions, with a corresponding difficulty in learning curve.
Allowing people to write debian/rules in other languages, allowing unusual
make flags, or allowing tricky variable manipulation outside of the make
language such as in the vdr packages just adds to that complexity and
learning curve. I think Debian suffers from that additional complexity.

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

Russ Allbery

unread,
Aug 18, 2010, 5:50:02 PM8/18/10
to
Charles Plessy <ple...@debian.org> writes:

> there is currently a discussion on debian...@lists.debian.org with a
> strong disagreement on what the Policy specifies for building binary
> packages, and what it should specify.

> http://lists.debian.org/msgid-search/4AE85D08...@e-tobi.net
> (I can prepare a summary if there is interest for this).

> In a first step, I think that it would be very helpful to clarify what
> is the build interface as of Policy 3.8.3. Currently the Policy
> specifies what the debian/rules file is, gives a special role to
> dpkg-buildpackage, and the build interface is extrapolated with
> conflicting interpretation among the developers.

> In a second step, I propose to go forward and open the possibility of an
> evolution of the constraints on the format of the debian/rules file,
> according to the consensus on what the build interface should be (which
> can be different from what it is as of version 3.8.3). This part is not
> independant from the discussion whether debian/rules should be callable
> interactively with no special environment variable set, or if
> dpkg-buildpackage should be the canonical tool for this usage.

This was one of two alternate proposals that came out of that discussion
concerning what interface is required for debian/rules. The other
proposal (require debian/rules to be a makefile) was adopted in Policy
3.8.4. I think that was an implicit choice of that approach over this
one, and reviewing the bug log, I don't think this proposal got consensus.

Accordingly, I'm marking this bug as rejected, but it will stay open for
some time in case anyone objects or disagrees with my interpretation.

--

0 new messages