Re: Possible framework for `debmake replacement'
Bruce Perens wrote:
>
> I too am dubious about the "compiler" form of deb-make replacement.
> The problem is that it does not catch up as policy changes. It would
> be very difficult to make a "compiler" form of rules builder that
> would automaticaly incorporate policy changes into existing packages
> as deb-make often does. Once you edit the generated script, you don't
> want to send it back through the tool again and lose your changes.
>
Good point.
I think we need to change the nature of the debian/rules file from
edited to generated (and so it should be better to change its name,
so we could handle both ways to build packages without shooting
anyone's foot).
As someone else pointed out, this compiler should have two inputs:
a policy formal description (in the dpkg package) and a package(s)
description (which could be one or more files in the debian/ dir)
and generate the makefile actually known as debian/rules.
The package description file should be able to have the precedence
over the policy description.
Then could be useful a dpkg-lint checker which can discover "unusual"
things and warn the maintainer and/or inform the QA testers about
things done differently as the current policy. It could be *really*
useful to test packages when policy changes: it could suggest changes
to be done in the package description file(s) to accomplish policy.
The maintainer should _always_ have the last word, which should be
explained somewhere in a debian/ file like readme.debian or so.
Fabrizio
--
+----------------------------------------------------------------------+
| fpolacco@icenet.fi fpolacco@debian.org - Using Debian GNU/Linux ! |
| 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E |
> Dog meat? Don't worry, Gwendolen, I'm on my way! [Wallace] |
+----------------------------------------------------------------------+
Reply to: