Goswin von Brederlow <goswin-...@web.de> writes: >> And for the record, I'm seeking input on the dh-exec implementation >> here. Keep the anti-executable-debhelper-foo thing in the other thread, >> please. > > But that is the actualy problem. The executable-debhelper-foo thing is > in many peoples optinion bad. > > Your implementation and the difficulties to handle the various debhelper > options like --sourcedir correctly show that it might not have been a > good solution afterall. Or at least not yet quite thought out and > finished.
It's a good solution, in my opinion, just one that could use a few little tweaks, like passing down the options to programs ran. > A general dh-exec that does tons of things could be nice. But if it can > only do variable susbtituion without breaking other debhelper options > then why not do the variable substitution in dh_install directly? All > the promised flexibility is of no use if it can't be used safely. Because it's easier to extend outside of dh, and can be first done on a per-package basis to experiment with it. (Yes, it would be bad if everyone started to do their own experiments, but one or two is fine, until the use-case gets a generic solution) > This doesn't mean it isn't possible to do more. Just so far no one has > succeeded to do e.g. rename on install without breaking stuff. And that > in itself is a big point against the feature. To be honest, I'm fairly happy with the current implementation. Even if it breaks --sourcedir and --that-other-option-I-never-heard-of-before, that can be documented, and all will be well. And if and when debhelper will start passing its options downwards, we can fix these two, too. -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zkes6a8m.fsf@algernon.balabit
