On Mon, Feb 08, 2021 at 10:29:13PM +0100, Raphael Hertzog wrote:
> On Tue, 02 Feb 2021, Jelmer Vernooij wrote:
> > One of the things that I've been wondering about is whether it would make
> > sense to have a configuration file in Debian packages that allows
> > maintainers to specify preferences for contributions. At the
> > moment, this is not a well-formed proposal yet - but I'm curious as to
> > your thoughts.
>
> I must say that we keep adding layers of complexity and this would
> just extend the amount of things that one should know about packaging.
>
> We need more consistency and not more choices. But in the end, those
> choices are differences that do already exist in practice.
>
> In the grand scheme of things, we should have a Debian-wide
> recommended way of handling packages and this configuration file
> would only be needed when a maintainer really wants to deviate from
> this recommended way.
>
> The DEP we need is the one that defines this default way of handling
> packages and contributions, and the file you want would only be a
> by-product of this.
On Tue, Feb 09, 2021 at 06:21:46PM +0100, Mattia Rizzolo wrote:
> On Tue, Feb 02, 2021 at 01:55:19PM +0000, Jelmer Vernooij wrote:
> > * Whether or not contributors can feel free to reformat
> > files (e.g. wrap-and-sort -a -v).
> > ("allow-reformatting" in lintian-brush.conf)
>
> On this, please also read https://bugs.debian.org/895570#13
>
> tl;dr: I honestly believe we should just decide on a format, and
> converge towards it.
> It apparently works quite well for python as a whole ecosystem, where
> now pretty much nobody is "against" pep8 (or even black!). There is no
> reason we can't manage to decide on a wrapping format and stick with it.
The argument you're both making is that we should have a single sensible
standard and then provide a way for those packages that currently
diverge (and possibly want to diverge in the future?) for specifying
so. That makes a lot of sense, and it would mean that:
* the cost of adding this file is only borne by those who diverge from
the standard
* requiring per-package files is less costly - larger teams could
(should?) just stick to the standard - and there is less need to
support a complicated per-team configuration
That addresses the main concerns I raised in my original message.
Using heuristics to figure out the style for a package is somewhat at
odds with defining defaults in the absence of explicit configuration.
However, in the absence of explicit configuration we can still use
heuristics to determine that the explicit configuration or standards
are blatantly not being followed by the package and acting
appropriately. This could result in:
1) not reformatting according to the selected style, i.e.
making changes but not reformatting, if supported by the tool
2) formatting according to whatever other style is being followed
(and detected)[1]
3) simply refusing to make any changes until the user reformats using
the (explicit or default) configured style
I don't think this needs to be explicitly mandated in the DEP, but it
would be relevant for any actual implementations of the DEP for the
reasons mentioned by Jonas in
https://lists.debian.org/debian-devel/2021/02/msg00138.html
On Mon, Feb 08, 2021 at 10:29:13PM +0100, Raphael Hertzog wrote:
> On Tue, 02 Feb 2021, Jelmer Vernooij wrote:
> > * Generally speaking, the preferences would be the same for
> > all packages maintained by a specific team/person. Having to copy
> > these preferences into every git repository in a set (e.g.
> > perl-team) seems tedious and unnecessarily repetitive. Maybe this
> > should live in a separate database somewhere, or perhaps it can be
> > specified in salsa somehow on a per-team basis?
> Somehow this ship has sailed, plenty of teams do commit debian/gbp.conf
> and debian/salsa-ci.yml in all their repositories. At least the GitLab CI
> has an URL include mechanism that makes it possible to create a team-wide
> configuration and include it.
Agreed that it's a common practice to have the same files duplicated
for all of the packages maintained by a specific team, but it still
doesn't seem ideal...
Since this is a common practice for other control files that would
benefit from per-team configuration, perhaps that's a problem that
should be solved separately for all of these files rather than
as part of this DEP.
> > * Should this really be a separate file, or could it be folded
> > in elsewhere?
> I don't know of anything else but if we create a new file, I'd rather have
> it in debian/source/ rather than right below debian.
+1.
What about one of:
* debian/source/style
* debian/source/preferences
* debian/source/contrib
Once these standards are defined and diverge can be specified, lintian
could also check for packages confirming to the standards.
Some of the things to standardize:
* a canonical style for debian control files and .dirs, .docs,
.examples, .info, .install, .links, .maintscript, and .manpages under
debian/
Perhaps something that matches an existing wrap-and-sort command
lines suggested elsewhere in this thread. (-bast?, -bastk?)
Would it be necessary to support multiple styles, or would this
merely specify that the package is being reformatted?
Perhaps this should depend on how many different styles are in use
today.
* whether debian/changelog should be updated when making chagnes
to the package, or whether that's done later based on e.g. VCS
commit messages.
The common answer across the archive today seems to be "yes", but
there are a fair number of packages that rely on "gbp dch" instead.
* last release to stay compatible with to ease backporting,
perhaps defaulting to oldstable for Debian, last LTS
for Ubuntu, ...
* perhaps whether low threshold NMUs are accepted for this package,
defaulting to no?
* anything else?
Cheers,
Jelmer
[1] I'm less sure about this.
Attachment:
signature.asc
Description: PGP signature