Sean Whitton <spwhit...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/>
