Web lists-archives.com

Re: Do we want to Require or Recommend DH

On 5/13/19 6:28 PM, Sam Hartman wrote:
>>>>>> "Thomas" == Thomas Goirand <zigo@xxxxxxxxxx> writes:
>     Thomas> Now, I have another example, which is quite the opposite one
>     Thomas> of what you gave as example:
>     Thomas> https://salsa.debian.org/openstack-team/debian/openstack-debian-images/blob/debian/stein/debian/rules
>     Thomas> Why would one want to switch that one to something else? The
>     Thomas> package, basically, consists of a shell script and a man
>     Thomas> page only. The minimalism of this package doesn't require an
>     Thomas> over-engineered dh sequencer, does it? I'm happy the way the
>     Thomas> package is, and I don't think I'd switch to the dh sequencer
>     Thomas> *UNLESS* someone has a better argument than "it's new", or
>     Thomas> "debian/rules will be smaller", or even "it's going to
>     Thomas> evolve without you even noticing it" (which is more scary
>     Thomas> than anything else, which is IMO one of the defects of the
>     Thomas> dh sequencer).
> Could you make an attempt at articulating this as an exception?

I agree this package is probably an exception.

On 5/13/19 7:42 PM, Holger Levsen wrote:
> - because it makes archive wide changes a lot easier.


Though I very much doubt this super-simple package will miss any
archive-wide change applied through modifying the way dh sequences
things. If this happens, it will mean we're over-engineering things.

> - it's also simpler to understand.

There, I don't agree. To fully understand how the dh sequencer works,
one must first understand the 6 mandatory debian/rules targets, and how
they are called. dh will hide everything. It isn't simpler, it *LOOKS*
simpler, but it's a way more complex.

When dh appeared, it took me months to accept it, because I didn't like
it was hiding everything. I appreciate why it's done, and I do use dh in
most of my packages, but it's still the case that I would prefer if it
wasn't hiding everything.


Thomas Goirand (zigo)