>>>>> "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.
But we can shift that boundary if we want to. The reason we've included
dpkg-dev in our boundary of things that we treat as singular is mostly
technical.
But boundaries (even of technical interfaces) can be placed for a
variety of reasons, some based around things like code maintainability
rather than technical necessity.
Factors like style, future evolution, and ease of deploying changes
affect how we as engineers treat abstraction every day.
Policy today has a number of requirements based on style.
We could allow each package to choose its approach for configuration
management. Instead, we have a number of guidelines. These guidelines
are not a technical necessity in a number of cases.
Instead, we have decided we value consistency for our users. We want
packages to have a reasonable configuration by default. We want certain
behavior on upgrades. We want to carefully control what happens for
conffiles. Again, not entirely because of technical necessity, but also
because we want a consistent experience across the distribution for our
users.
We might also want a consistent experience across our distribution for
maintainers of packages beyond the minimum consistency required for our
tools to work.
If we do, shifting interface boundaries to permit that is entirely
reasonable.
It seems to me that whether something is a layering violation depends a
lot on what the layers are intended to do.
And sometimes refactoring is as much about rethinking why you have the
layers as actually moving things around.
Just my initial thoughts on this.
--Sam
