Re: Do we want to Require or Recommend DH
On Tue, May 14, 2019 at 11:30:11AM +0200, Andreas Tille wrote:
> On Mon, May 13, 2019 at 10:22:32PM +0300, Adrian Bunk wrote:
> > On Mon, May 13, 2019 at 08:33:44AM -0400, Sam Hartman wrote:
> > >...
> > > Andreas Tille's explanation (quoted below) is typical of what I've heard
> > > in this area.
> > >
> > > >To come back
> > > >to the question: I'm positively convinced that we should strive to
> > > >unify our packaging as much as possible and in terms of d/rules file dh
> > > >is obviously the default we should pick. I'd go that far that lintian
> > > >should issue some warning at "pedantic" level if there is no comment:
> > > >"I'm not using dh because ... ". In other words: Use dh in debian/rules
> > > >should make it into policy.
> > >
> > > >The rationale is that dh makes it extremely easy to understand other
> > > >d/rules files. Specifically in freeze like now it is easy to touch
> > > >other peoples packages (just done this several times in the last weeks
> > > >and luckily close to all used dh). Its the point of teamwork (and I
> > > >consider all people touching official Debian packages as a team) to make
> > > >things simple for team mates. I consider it a valid request to every
> > > >single maintainer to respect that other people have good reasons to
> > > >change her/his package.
> > >...
> >
> > Based on this rationale, Andreas should stop using d-shlibs.
> >
> > Weird tools on top of dh are not that different from using a weird
> > buildsystem when debugging other peoples packages, and d-shlibs is
> > something I've seen involved in bugs more than once.
>
> Its the first time that I hear criticism about d-shlibs usage
It is fine in the current "maintainer can do anything" world.
> and I'm
> fine with discussing this but I'd prefer not to spoil the current
> thread.
>...
It is actually part of it, due to:
>...
> As far as I understood the point of the discussion is that we want to
> get the whole archive more uniform to reduce the potential causes for
> bugs *in* *the* *future*.
>...
If this is the point, then weird tools on top of dh are part of the
problem just as weird buildsystems are.
>...
> > When you debug for the first time a non-trivial problem in a complex
> > package like src:gcc-8 or in a package in an ecosystem like Haskell you
> > can easily spend hours just for figuring out what is actually going on
> > or how to pass additional flags. Whether or not the build machinery is
> > using dh is not a big difference when you have to understand what is
> > actually going on.
>
> I for myself prefer to debug code based on the same tool set.
>...
This is pretty much impossible.
dh is nice when it supports whatever you want to do,
but for everything else it is just another layer you
have to understand when debugging and fixing problems.
Imagine you want to make ghc pass an additional flag to gcc.
The layering is as follows:
Debian haskell scripts
upstream build system
ghc
gcc
You end up at questions:
How can I tell ghc to pass a parameter to gcc?
How can I tell the upstream build system to pass a parameter to ghc?
How can I tell the Debian haskell scripts to pass a parameter to the
upstream build system?
debian/rules is already a 3-line
#!/usr/bin/make -f
include /usr/share/cdbs/1/rules/debhelper.mk
include /usr/share/cdbs/1/class/hlibrary.mk
It wouldn't help you if that would be changed to a 3-line
#!/usr/bin/make -f
%:
dh $@ --with haskell
In either case there is a huge Haskell-specific build machinery you
have to understand for making some kinds of debugging or changes.
> Kind regards
>
> Andreas.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Reply to: