>>>>> "Bill" == Bill Allombert <ballo...@debian.org> writes:
Bill> On Sun, May 12, 2019 at 08:36:16AM -0400, Sam Hartman wrote:
>>
>> 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.
Bill> Note that policy does not actually require that dpkg is
Bill> used. Instead it goes to great length to describe what is the
Bill> interface to dpkg that packages must relie on.
That's not really true.
policy>In the normative part of this manual, the words *must*, *should* and
policy>*may*, and the adjectives *required*, *recommended* and *optional*,
policy>are used to distinguish the significance of the various guidelines in
policy>this policy document. Packages that do not conform to the guidelines
policy> denoted by *must* (or *required*) will generally not be considered
policy> acceptable for the Debian distribution. Non-conformance with
policy> guidelines denoted by *should* (or *recommended*) will generally be
policy> considered a bug, but will not necessarily render a package unsuitable
policy> for distribution.
Then later in 4.9:
policy> Both "binary-*" targets should depend on the "build" target, or on
policy> the appropriate "build-arch" or "build-indep" target, so that the
policy> package is built if it has not been already. It should then create
policy> the relevant binary package(s), using "dpkg-gencontrol" to make
policy> their control files and "dpkg-deb" to build them and place them in
policy> the parent of the top level directory.
Thus it is a bug to not use dpkg-genchanges and dpkg-gencontrol and
dpkg-deb.
Bill> This makes
Bill> sense since this allow dpkg to evolve without breaking package
Bill> policy compliance.
Actually, I'd argue that mandating use of dpkg-genchanges et al makes
sense, as policy does today.
It allows dpkg to evolve and do things like update the checksums we use,
add new formats for changes files, etc and get wide adoption quickly
across the archive.
I'm not sure what sort of evolution you're talking about, but I think we
get better evolution by using a single tool that can easily be changed
than by using multiple tools to approach the same purpose.
Using multiple tools allows us to experiment and allows for cases where
different workflows/packaging designs work in different situations.
However it makes it harder to deploy new practices.
I think it's clear that at the dpkg-dev level, the benefits of multiple
tools are not justified, so policy correctly tells people to use tools
from dpkg-dev.
If you look at the question with a policy hat on, we might be asking
ourselves whether we have enough experience with the next level up that
telling people to use one tool at that next higher level is also worth
it.
