Hi, On 30.03.20 00:52, Guillem Jover wrote: > And, of course there are always going to be remaining sticking points > not covered by features I or others have in mind, but IMO their presence > will still mean there's something to improve somewhere. This is the same debate we had in a lot of other places by now: do we want a descriptive interface that requires explicit provisions for every case, or an imperative interface that requires programming skill to use? For packaging, we have an imperative interface, and a declarative wrapper on top that handles most of the simple cases. That works well, and I'm not sure there is much potential for improvement there, because even if we switched to a declarative-by-default system, we'd still need an imperative escape hatch for those cases not covered yet. The namespace below debian/ has not been tightly regulated so far. Any name that isn't mentioned in Policy is free for the package to use for anything, and access to it is brokered again through debian/rules (with "clean" being pretty much the only operation allowed on it). In that regard, the debian/ directory is not much different from the rest of the source tree. We still have quite a few packages doing in-tree builds because the upstream build system does not work for out-of-tree; these would still require cleaning through "debian/rules clean", so we won't get by without our escape hatch for quite a while. Unrelated to Policy, debhelper could move all of their intermediate files below debian/debhelper, that would probably get us 90% of the way without requiring a transition period. Simon
Attachment:
signature.asc
Description: OpenPGP digital signature