[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFC: Standardizing source package artifacts build paths


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.


Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: