On Sun, May 12, 2019 at 08:36:16AM -0400, Sam Hartman wrote:
> >>>>> "Sean" == Sean Whitton <spwhit...@spwhitton.name> writes:
> 
>     Sean> Hello,
>     Sean> On Tue 30 Apr 2019 at 09:28AM -04, Sam Hartman wrote:
> 
>     >> I plan to start with the question of preferring dh as a package
>     >> build tool.  https://trends.debian.net/ has already added not
>     >> using dh as a "package smell" and so I'd like to validate whether
>     >> the project agrees with that.  I'll start a discussion on
>     >> debian-devel about this issue the week of May 5.  While you can
>     >> of course start a discussion earlier or even start a meta
>     >> discussion about whether we should have a discussion or whether
>     >> I'm the right person to start it, I hope that doesn't happen.
>     >> I'm organizing some material to frame the discussion.  I
>     >> understand that if we make a change it is likely to be a policy
>     >> change.  So perhaps I could have started the discussion on
>     >> debian-policy rather than debian-devel.  I think that for the
>     >> high level question debian-devel is more appropriate.  If we get
>     >> down to details then shifting to -policy is likely to be a good
>     >> choice.
> 
>     Sean> Policy currently documents an interface, and debhelper/dh is
>     Sean> an implementation of large parts of that interface.
> 
>     Sean> Thus, it would be something of a layering violation if the
>     Sean> normative part of Policy were to require or recommend using a
>     Sean> particular tool to implement its other normative content.
> 
> I'll admit that I've been mostly focusing on how to canvas the project
> about what it wants rather than how to implement it.
> 
> If we as a project actually want to require dh in some/most situations,
> we ought to be able to figure out some way to say that.
> 
> Now given our community it's entirely possible that the question of
> whether it's a layering violation in our existing policy architecture
> may influence whether people want to require it, so we may have to face
> that sooner rather than later.
> 
> That said, it's been my experience as an engineer that interface
> boundaries shift over time and that there are a lot of factors that
> influence where we draw them.
> As you pointed out in your original mail, we do recommend specific tools
> including dpkg-genchanges and dpkg-gencontrol.
> I totally could generate a changes file without using those tools.
> In most cases we'd agree that is a bug.
> 
> It seems fairly obvious that dpkg-dev is special and singular.

Note that policy does not actually require that dpkg is used. Instead it
goes to great length to describe what is the interface to dpkg that
packages must relie on. This makes sense since this allow dpkg to
evolve without breaking package policy compliance.

Doing the same for dh would require documenting the full dh interface.

Cheers,
-- 
Bill. <ballo...@debian.org>

Imagine a large red swirl here. 

Reply via email to