Hello, On sekmadienis 12 Birželis 2011 00:10:34 Roger Leigh wrote: > On Tue, Jun 07, 2011 at 03:52:01PM +0100, Roger Leigh wrote: > > On Tue, Jun 07, 2011 at 01:47:41PM +0100, Roger Leigh wrote: > > > On Tue, Jun 07, 2011 at 08:12:15AM -0400, Joey Hess wrote: > > > > Roger Leigh wrote: > > > > > I think I may have proposed something similar to this patch before, > > > > > but I can't find it in the BTS. > > > > > > > > It caused significant slowdown (due to running every debhelper > > > > command twice with -a and -i) and quite likely broke packages due to > > > > running make install twice, so was removed. > > > > > > > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604563#77 > > > > > > > > 657852b56b0d835afd4e45407d6e8d217c63ab20 > > > > > > I'm sure we can improve the performance with some additional work. > > > > > > Currently we have the "sequence dependencies" as a separate > > > list, not associated with the sequences themselves. It would be > > > possible to put them directly into the sequence list, e.g. with > > > a prefix such as "rules:build" which would make dh invoke > > > "debian/rules build" rather than the command directly. This would > > > permit the rules targets to be run at any point in a sequence. > > > > Patch attached which includes the rules in the sequences. This should, > > as far as I can tell with my testing, eliminate the performance issues > > you mentioned above. With the rules targets in the sequence list, it > > also means you can potentially also use them as sequence points for > > --before etc. > > I've greatly simplified the patch. This is now much more > straightforward and works well for me. It has the performance > improvements of previous patches, but with greatly reduced > complexity. Examples: > > This has been working beautifully for me, and means you now get > uniform behaviour from debian/rules $target and dh target including > when being invoked as a sequence dependency.
This has a potential to go very deep with make (binary) -> perl (dh) -> make (install) -> perl (dh) -> make (build) -> perl (dh). We have already seen what negative effect this has on e.g. make -jN. IMHO, bugs will be hard to understand and fix with such level of recursion. Personally I don't understand what's the issue here. If debian/rules has no explicit build,install,binary etc. targets (which will continue to be >= 90% of cases), current dh implementation works just fine. If debian/rules has them, it should be up to maintainer to make sure they work as supposed to (with respect to policy). E.g. if maintainer re-implements binary, (s)he should define needed dependencies in the rules file directly. From my experience, it is much better not to touch top targets at all and to implement all customizations via override_% targets. Maybe dh could export which debian/rules sequence it runs whenever override is called. -- Modestas Vainius <[email protected]>
signature.asc
Description: This is a digitally signed message part.
