Modestas Vainius wrote: > But this all seems like re-implementation of make in perl
Well yes, that's essentially what dh has always been guilty of. :)
> Anyway, I guess it is a good thing to be policy complaint. So I suggest
> adding
> a dh restriction that standard targets have to be explicit. Then dh could
> check if they exist before running them:
>
> if (defined $rules_target && rules_explicit_target($rules_target)) {
> run it
> }
>
> In my opinion, this would be rather reasonable. Then these changes won't
> affect packages which don't need them.
So, this might help. It could at least avoid the deep calls for most
packages.
> > I somewhat agree, but something will need to be done for split
> > build-indep/arch and install-indep/arch. One thing I suggested before is:
> >
> > override_dh_auto_install:
> > dh_do -a -- $(MAKE) -C debian/build install
> > DESTDIR=$(CURDIR)/debian/install dh_do -i -- $(MAKE) -C debian/build/po
> > install DESTDIR=$(CURDIR)/debian/install
> >
>
> Yes. That's indeed a problem with non-obvious solutions. If I need to do
> something like this in the override after dh_installdirs, I just do:
>
> if [ -d debian/package ]; then do_custom_stuff; fi
>
> Another solution is:
>
> if [ -n "`dh_listpackages -i`" ]; then do_indep_stuff; fi
> if [ -n "`dh_listpackages -a`" ]; then do_arch_stuff; fi
>
> ... whenever dh is called via *-arch or *-indep target (i.e. post build at
> the
> moment). Obviously, this is not very obvious unless maintainer knows about
> internals of DH_INTERNAL_OPTIONS :) So maybe:
>
> if dh_isapplicable (-ppackage|-a|-i); then do_custom_stuff; fi
>
> would be nice to have.
Yes, my proposed dh_do basically runs the specified command iff any of
the packages selected by standard debhelper flags would be acted on in
its context. So dh_do -ppackage -- foo
--
see shy jo
signature.asc
Description: Digital signature
