On Mon, 2020-03-30 at 13:54:27 +0200, Simon Richter wrote: > 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?
This proposal is orthogonal to that debate. Of course some things might need declarative interfaces, but that does not mean that excludes or would disallow programmatic ones. The proposal mostly deals with defaults and conventions, for already existing interfaces. For example for dpkg-shlibdeps or dh_install to look automatically under these directories. Some of these commands might also grow new options to override those defaults, when they do not yet have them. So it might actually increase the control possibilities! (But just to appease whoever else might be worried, while at least Niels and I have been working and have plans to further improve the declarative packaging support, we also are extremely aware that we'll always need to support escape hatches for programmatic interfaces.) > 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). Again the proposal is not to tighly regulate anything. It would be a matter of convention and defaults. If people do not want or cannot use these, then that'd be fine too. Perhaps this was not really clear from the initial proposal, or the fact that it was proposed at all made it sound more forceful than it was intended. Also policy does list many of these default pathnames already, most in its appendices. Because that's what dpkg has used as defaults for a very long time. Of course that has not disallowed debhelper, f.ex., to use some different pathnames over time. The purpose of the proposal was to try to create a new convention and coordinate over 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. Nothing would force antyhing to place stuff anywhere, as long as the convention is not used. The point as mentioned above, is that if you need, say, an out-of-tree pathname, then there would be conventions to use, and the tools would have these as defaults or easy support for them (for example with options to select different build flavors). If for whatever reason these cannot be used then overrides would still be possible for non-internal stuff, like it is currently the case. > 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. This would still be quite unsatisfactory and not give the important properties proposed, and moving all intermediate debhelper stuff would still require a transition, or it would need to leave things behind. Thanks, Guillem