Re: Bits from the DPL (April 2019)
Sean Whitton <spwhitton@spwhitton.name> writes:
> ISTM that dh is a special case because it basically tries to implement
> as much of Policy as is automatable, either in its own code, or by
> calling other tools in the right way.
> In particular, even if dh were used by every package, we would not want
> to replace all the parts of Policy it implements with "use dh". That's
> because maintainers still need to understand all the rationale for the
> things dh does, and also because they need to get things right when they
> write their own override_ targets, bypassing bits of dh's logic.
Yes, I definitely agree with this. I think this is one of those cases
where we need to continue to dig into exactly what is being done under the
scenes, because almost everything in the dh sequences have to be
overridden in at least one package somewhere, or at least further
modified, and Policy has to provide the context and understanding required
to make those modifications.
I would say this is akin to shlibs and symbols files. You *mostly* just
need to create a configuration file and then run dpkg-gensymbols,
generally via dh_makeshlibs, but Policy does need to provide some of the
details of what's going on under the hood here both because it's required
to understand when to use some of the optional features of those
configuration files, and because sometimes dpkg-gensymbols needs to be
guided or overridden.
That said, just as a matter of style and usability, we should describe the
common case first and make it clear that one doesn't have to open up the
details unless something isn't working right.
> This is why it seems odd to me to have "You should use dh." in Policy,
> in a way that does not arise for the idea of Policy
> recommending/requiring other tools to implement its requirements.
> When I say "layering violation", I'm not trying to stand on principle in
> any sense. Moving the interface boundary such as to have Policy
> recommend using dh_shlibdeps, say, is not odd in the way that the
> possibility of Policy recommending/requiring use of the whole dh
> sequencer is.
Yes, this objection makes a lot of sense to me. I think I see why that
bothers you.
The path that, to me, navigates out of that difficulty is to focus on
Policy's role as an instruction manual. Rather than thinking of Policy as
a comprehensive description of one layer of the packaging ecosystem, we
can instead switch (and it is a switch -- this isn't what we've done in
the past) to thinking of Policy as a technical instruction manual for
packagers. And like a good instruction manual, it can document both the
common path for most people, and then have an "advanced usage" section
that digs into the details for special cases or difficult problems.
The larger problem here, and what I think is a bit of the elephant in the
room, is that doing all of that requires resources, specifically time and
energy to do all the necessary writing and editing. Which we're
chronically short on.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: