Your message dated Sun, 8 Mar 2009 16:47:27 +0200
with message-id <[email protected]>
and subject line Re: debhelper: dh addon interface enhancement proposal -
command alias support
has caused the Debian Bug report #490885,
regarding debhelper: dh addon interface enhancement proposal - command alias
support
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
490885: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=490885
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: debhelper
Version: 7.0.15
Severity: wishlist
Tags: patch
Hello,
I have been exploring ways to replace my customized CDBS setup with a new
debhelper v7 dh tool. CDBS offers custom build system extenstion points via
hooks and specially named variables. Hence you can write your own common
customized build system based on CDBS.
If I understand correctly, dh sequence addons are supposed to provide such
extensibility point. However, I found them limited in a few ways. Basically,
addon author cannot manipulate what arguments are passed to the individual
sequence commands. debhelper defaults are not always what is wanted.
Therefore, I think there is a need to extend addon interface with the command
which would allow the addon to specify arguments to be passed to the
individual dh_* helper programs. Actually, I went one step further and propose
support for command aliases. This way dh can be made to run different real
command when executing a specific sequence command (which then becomes the
alias (or the identifier) for the real command and its arguments). You may ask
how aliases are different than a few calls to insert_{after,before}() and
remove_command(). Well:
1. Setting the alias does not change command position(s) in the sequences.
This feature could also be implemented via replace_command() call.
2. Aliases can be particularly useful to replace standard dh_program
implementations with custom scripts without breaking existing
until/after/before parameters. For example, maybe I want to use my own set of
custom dh_auto_* scripts to support a weird build system. Then I could
implement a single dh_auto_weirdbuildsystem script which would handle
configure/build/install/clean switches and map them to the respective standard
dh_auto_* sequence commands. Without alias support, I would have to write 4
different scripts (or create symlinks) like dh_auto_configure_weirdbuildsystem
dh_auto_build_weirdbuildsystem etc. since dh sequence commands need to have
unique name.
3. Among other advantages, ability for addon to specify what custom arguments
should be passed to the individual debhelper programs, allows addons to
implement some sort of automagic like CDBS does, e.g. auto docs etc.
The attached patch is the implementation of this proposal. Only one new addon
API is added (set_alias_command()) and unless it was called from the addon,
behaviour of the patched dh should not be any different than behaviour of the
unpatched dh.
--
Modestas Vainius <[email protected]>
--- dh 2008-07-09 23:16:57.000000000 +0300
+++ dh 2008-07-14 00:17:49.000000000 +0300
@@ -95,6 +95,18 @@
Remove I<existing_command> from the list of commands to run.
+=item Debian::Debhelper::Dh_Lib::set_alias_command(command_alias, real_command, command_arg(s) ...)
+
+Turn I<command_alias> command into an alias for the I<real_command> with the specified
+I<command_args> (if any). You can use this function either to pass additional arguments
+to the I<command_alias> call (if I<command_alias> == I<real_command>) or replace a standard
+command with a custom implementation. Please note, however, that in the latter case,
+implementation of the I<real_command> has to disguise as I<command_alias> in the debhelper
+logs because B<dh> tracks I<command_alias>, not I<real_command>.
+
+To unset the I<command_alias> and turn it back to the normal command, just pass the alias
+in the I<command_alias> parameter and do not set other parameters.
+
=back
=cut
@@ -296,6 +308,7 @@
unshift @{$dh{WITH}}, "python-support";
# sequence addon interface
+my %command_aliases = ();
sub _insert {
my $offset=shift;
my $existing=shift;
@@ -330,6 +343,23 @@
}
}
+sub set_alias_command {
+ my $alias=shift;
+ my $real_command=shift;
+ my @ar...@_;
+
+ if ($real_command) {
+ my @cmd;
+ push @cmd, $real_command;
+ push @cmd, @args if (@args);
+ $command_aliases{$alias} = \...@cmd;
+ } else {
+ # Remove the alias from the alias list which effectively makes
+ # the alias a normal command again
+ delete $command_aliases{$alias} if exists $command_aliases{$alias};
+ }
+}
+
foreach my $addon (@{$dh{WITH}}) {
my $mod="Debian::Debhelper::Sequence::$addon";
$mod=~s/-/_/g;
@@ -456,11 +486,24 @@
sub run {
my $command=shift;
- my @optio...@_;
+ my $alias;
+ my @options;
+ # Check if alias has been defined and if so, use it
+ if (exists $command_aliases{$command}) {
+ $alias=$command;
+ my $realcmd=$command_aliases{$command};
+ $command=shift @$realcmd;
+ push @options, @$realcmd if (@$realcmd);
+ push @options, @_;
+ } else {
+ @optio...@_;
+ }
# 3 space indent lines the command being run up under the
# sequence name after "dh ".
- print " ".escape_shell($command, @options)."\n";
+ print " ".escape_shell($command, @options);
+ print " (via \`$alias\' alias)" if (defined($alias) && $alias ne $command);
+ print "\n";
if (! $dh{NO_ACT}) {
my $ret=system($command, @options);
signature.asc
Description: This is a digitally signed message part.
--- End Message ---
--- Begin Message ---
Hello,
I no longer consider this as a good idea. And dh_overrides stuff does the same
in a much cleaner way. Thus closing...
--
Modestas Vainius <[email protected]>
signature.asc
Description: This is a digitally signed message part.
--- End Message ---
