Re: RFC: Standardizing source package artifacts build paths
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
Reply to: