Bug#640874: leave: debian/rules is not a Makefile
On Thu, 08 Sep 2011, Josip Rodin wrote:
> > The API is not the only thing to take into account. Using anything else
> > than make is unexpected for most other developers (some of them who might
> > have to NMU your package at some point).
>
> I agree, but that argument goes both ways - we already allow developers to
> use obfuscated makefiles, which has the analogous potential for difficulty.
Sure enough, but why do you insist on doing as badly as some other are
doing?
On my side, I'm not doing poor work just because others have done so and
nobody complained yet. :-)
> > Yes, but it's also not worse than having to read the sources of a shell
> > script.
>
> Ahem, so I must quote it:
I don't think it changes my point of view. I know way better the default
behaviour of debhelper than the resulting behaviour of your package.
And I know debhelper allows for massive changes that would not be possible
if all packages were doing like you.
On the contrary, I see that your package does nothing fancy that could
justify the use of something else than what is the de-facto standard.
Your script is trivial to convert to a Makefile.
> Is the compliance with policy easier to read from the obfuscated makefile
> example at the top, or from the trivial shell example above?
It depends on one's background. A casual DD knows debhelper way better
than a custom shell script.
It's quite possible to you missed something in your package and it's not
easy to verify it just from reading the rules files. If you use debhelper,
you know that all the cases that can be automated are already taken care
of. So I'm more confident in the policy compliance of a 4-line dh-based
rules file than of your schell script.
> > And still, this is a Makefile so you can quickly reuse Makefile snippets
> > that others have been writing to add support for supplementary targets
> > (like get-orig-source) or even to influence the environment (like the
> > Makefile snippets that dpkg 1.16.1 is going to provide).
>
> Same can work for pretty much any other similar language.
Except that by standardizing on make we avoid to have to duplicate
those things for multiple languages!
> > So I really don't understand why you insist on keeping debian/rules
> > as a shell script. Moving it one level deeper in the process tree
> > does not strike me as a big performance/readability loss, certainly not
> > one worth spending the time of tech-ctte members on such a case.
>
> So you want me to satisfy the letter of the policy but break its spirit? :)
You seem to be arguing that you're following its spirit but not the letter
of it. So yes, please follow the letter of it in whatever way that you believe
is coherent with the spirit of Debian.
> No, "Debian" did not decide to explicitly ban non-shell rules files at any
> point in time, it was a leftover from a text conversion that never got
> fixed.
I'm convinced this change would have been adopted even if it had been
proposed in a explicit manner.
> It remained so until the present day, and it works in practice. So why
> break it?
Why make dozens of developers lose time on this issue when it takes 5
minutes to convert your shell script and when you have already shown that
this rule is not restricting the flexibility we already have ?
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
Reply to: