Modestas Vainius <[email protected]> writes:
> I don't understand why you want another file for this. Sequence setup
> naturally *belongs* to debian/rules, it should be visible from there.
If dh(1) is in use, there are not many sequences in debian/rules. The
point of moving to single dh(1) is to move away from hand maintained and
possibly long debian/rules file.
There is a difference in maintaining packages and "learning" packages. The
dh(1) addresses the scalability to being able to maintain numerous
packages with ease.
Starters usually do it "by hand" with traditional debhelper (I did). You
end up writing copies of debian/rules files; over and over. They are
mostly the same and contain duplicate code that are better handed to dh(1),
thus simplifying the maintenance.
As explained, compare this to traditional debian/rules file:
>> There is no need to write full blown debian/rules when
>> it could simply read:
>>
>> # Makefile debian/rules
>>
>> %:
>> dh "$@"
>>
>> And the commads not used listed in:
>>
>> debian/dh_norun
>>
>> This would be both simple, elegant and maintenence friendly.
>
> It might be elegant, but it's no way simple. You add another file,
> which is rather unexpected dh interface detail for contributors to
> learn.
Maintaining separate files under debian/* directory is much better way
than a monolithic debian/rules. I understand that it may look like "more
clear" to have single file to do it all: it cerainly is easy for a new
maintainer to study and undeerstand. But as experience has shown, the
separate files approach:
* is scalable
* can be versioned (version control) and modified independently.
Thus bits and pieces can be even shared between projects.
* they separate certain logical structures to their own spots. This
unifies usage accross all packages.
* they are easier to process with external tools
like maintainer scripts. You can't edit or extract content from a
monlolithic debian/rules in any straight forward manner.
Examples of decoupling can be witnessed everywhere. The exim4 package
is a fine example how the maintenance in separate files makes upgrades
a breeze because you can merge changes file-by-file basis instead of
having to have to deal with monolithic changes in one file.
The RedHat /etc/profile.d/ is another fine example
Various others, lie /etc/apt/conf.d/ directories.
Joey has presented ways how the makefile could be modified to prevent
running extra dh_calls in Bug#560421, but as a generic solution it would
be more elegant to stadrdize to a single file. Otherwise everyone cook
their own overrides in debian/rules however they happen to write them
(not all are GNUMakefile experts).
debian/dh_norun
The improved solution would be for the debhelper to heuristically guess
automatically which rules need not be run according to files in debian/
directory -- thus making this almost transparent.
But we know programs cannot make perfect guesses, so there would always
be a need to specify which dh_* calls are not needed. A debian/dh_norun
would be a generalized solution.
Jari
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
