Thanks for wrap-and-sort!  It's great to have nice canonicalized-form
debian packaging.

Using wrap-and-sort with -ast provides the simplest, cleanest diffs as
things change, while still producing an easy-to-read debian/control.

I think these three options (--wrap-always, --short-indent,
--trailing-comma) should be the default.  (this might mean adding
inverted options for the people who really insist on using
wrap-and-sort in some other way).
--- /etc/devscripts.conf ---

--- ~/.devscripts ---
DEBSIGN_KEYID=0EE5BE979282D80B9F7540F1CCD2ED94D21739E9

Hi Daniel,

You should also check out cme :)

I agree, that's also the one I love the most ^^

I'd like to converge togethre with cme, so I'm CCing its maintainer to
see whether he has an opinion.  If so I'd clone the bug so he can do it
as well.
(TTBOMK cme doesn't allow configuring this detail, it only does the
equivalent of plain `wrap-and-sort` in this regard).

Hi

Sorry for the late reply

I can only agree :-D

I don't have a very strong opinion on what should be the canonical format of
debian control files.

I do believe that we should have one so tool writers can have a reference to
implement and people would not see changes when using different formatting or
generation tools (e.g dh-make-perl, cme, wrap-and-sort).

That said, I think that having formatting options (like --wrap-always --short-
indent) kind of defeat that purpose because people have different ideas on
what looks best.

Back to cme and wrap-and-sort, I'd really like to converge on formatting so
that both tools provide the same output (I've already changed the way
dependencies are sorted to match wrap-and-sort algorithm).

If we allow formatting options, these options should be saved in a file
(should that be a local or global conf file ? or both ?) so that cme and wrap-
and-sort can produce the same result with a simple command.

yes. Some part of cme are generic (for cme dpkg, cme ssh, cme systemd...) and
do not support formatting options.

I'm currently simplifying the reader/writer classes (aka backend) so adding
formatting options to cme should be easier.

I've cc'ed debian-perl team, they often have good ideas to smooth packaging
workflow.

Thoughts ?

All the best

Dod

makes sense to me.

sure, but they're all wrong except for me, right? :P

perhaps the options could go someplace like debian/source/canonicalize ?

As a user of -satb, I'd like to point out that the flags are not all
equal. Two of them support a (more objective?) desire that "addition to
a list in line-based VCS should have no deletions". That is -at, whereas
-s is a subjective prettifier and -b could remove information, hence -k.

To make that work as a default, there would need to be something like an
--short-preferred-unless-existing-indent to prevent constant
reformatting. I disagree with jonas on the importance of -s because I'm
not convinced that field names change, especially not often.

sorry, going by the current default, that should be
--align-preferred-unless-existing-short

To me, all the flags in -ast are objectively superior to their
counterparts. In the case of -s even more so, in addition to what has
been mentioned of avoiding reindenting on field renames which does not
necessarily mean the official field name gets changed (which is indeed
very unusual), but the field being renamed in debian/control, say from
Recommends to Suggests; it is also superior because:

 1) it avoids VCS noise, by not putting the first value on the first
    line as the field itself,

    Depends: foo,
             bar,

    instead of:

    Depends:
     foo,
     bar,

 2) it allows trivial copy&paste or syncs, between say build-dependencies
    and run-time dependencies. Say you have this:

    Source: foo
    Build-Depends: some-dep-dev,
                   other-dep-dev,

    Package: foo-dev
    Depends: some-dep-dev,
             other-dep-dev,

    which means you have to copy, possibly remove the field, then
    reindent, which is rather annoying.

I agree that -b is something else entirely, and in many cases I prefer
ordering depending on relationship, layers or importance of the
packages involved.

See above. But, I'd actually say it's perhaps as important or more
than -t! :)

Thanks,
Guillem

Time to join this discussion. The current default was the preference of
the author 14 years ago. My taste has change a bit since then. I am open
to change the default. --trailing-comma for wrapped lines is a good
idea, --short-indent is okay. I don't like --wrap-always in case there
are only two or three entries.

The new default should not only based on the preference, but also on
what is used the most. Can someone collect the information: which teams
use which options, how many packages use what?

When we change the default, the parameters to disable those again need
some short options.

Hi Benjamin,

I did some unscientific research on codesearch looking for d/changelog entries
mentioning `wrap-and-sort -` (i.e. wrap-and-sort with some options). This is
the query:

https://codesearch.debian.net/search?q=path%3Adebian%2Fchangelog+wrap-and-sort+-&literal=1

Apparently -a is the single most used option, very often used together with
-s and -t. I found similar results by searching GitHub:

https://github.com/search?q=path%3Adebian%2Fchangelog+%22wrap-and-sort+-%22&type=code

Looks like salsa (GitLab Free) doesn't allow to do instance-wide code searches.

If we want short parameters for the --no-<action> parameters I think the
most sensible option are capital letters (e.g. -T for --no-trailing-comma).
In [1] I added the --no-<action> options using argparse.BooleanOptionalAction,
which we won't be able to use if we also want short options (we'll need a
full parser.add_argument() definition for each I believe). Less nice but
not a deal breaker.

As not all the people reading the bug may know, there is now a MR aiming at
changing the defaults [2].

Cheers,

Paride

[1] https://salsa.debian.org/debian/devscripts/-/merge_requests/390
[2] https://salsa.debian.org/debian/devscripts/-/merge_requests/392

Hi,

I disagree that the new default should be what is used the most. For example
debhelper versions do not become the default only after they are used the most.
The thing that makes switching defaults easier for debhelper is the explicit
opt-in for a new debhelper compat version which we don't have for wrap-and-sort
and I think it would very much be over-engineering to add such a feature for
something that is, in my opinion, of very little consequence. Furthermore, I
would not be surprised if many people using wrap-and-sort use the default
expecting that this is what is most well-liked by the project (because why else
would it be the default?). The question was asked in this email sub-thread:

https://lists.debian.org/161289428547.4135738.4002254931040787156@auryn.jones.dk

In that thread, same as in this bug, -ast was proposed as the default and
unless I missed something, there were no objections on debian-devel. Some even
argued, to make -b the default as well. So instead of asking "what is used
most" I'd like to ask, are there users of wrap-and-sort without -ast who would
be strongly against having to pass -AST to overwrite a potential new default?

That being said, I downloaded all debian/control files for all 36832 source
packages in Debian and ran the following shell script on them to figure out how
many source packages comply with which wrap-and-sort set of options:

for p in control/*; do
	rm -f debian/control;
	ln -s "../$p" debian/control;
	for opt in "" -a -as -ast -astb -at -atb -ab -s -st -stb -sb -t -tb -b; do
		wrap-and-sort --dry-run --file=debian/control $opt \
			| grep --quiet debian/control \
			|| echo $p >> w-a-s$opt;
	done
done

It's of course still not possible to say whether a control file adheres to a
certain wrap-and-sort formatting style by accident or intentionally. Also,
packages can easily fall in multiple categories at the same time, for example
packages with only a single binary package which comply with -ast will
automatically also comply with -astb. There are also packages which comply with
-ast as well as with no options at all simply because they have no
Build-Depends nor Depends fields in debian/control. Here is the result sorted
by popularity in ascending order:

    96 wrap-and-sort -st
    96 wrap-and-sort -stb
   434 wrap-and-sort -as
   465 wrap-and-sort -tb
   489 wrap-and-sort -t
   579 wrap-and-sort -atb
   641 wrap-and-sort -at
  1341 wrap-and-sort -sb
  1405 wrap-and-sort -s
  2381 wrap-and-sort -astb
  2705 wrap-and-sort -ast
  2732 wrap-and-sort -b
  3020 wrap-and-sort
  3950 wrap-and-sort -ab
  4089 wrap-and-sort -a

So, wrap-and-sort -ast is very popular but it is not as popular as the current
default.

Do with that data what you wish. :)

Thanks!

cheers, josch

Hi josch and thanks for this analysis. I'll try to recap where we are at this
point, focusing only on -ast (I'll ignore -bk here).

1. This bug (#895570) requests -ast to be the default. The proposal received
mostly positive feedback, however bdrung doesn't like -a in case there are
only two or three entries. He also thinks we should consider what is already
popular.

The research done in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895570#50 looks good.

Do we have now agreement to default to -ast or -astb for packages that have
Debhelper 14+?

I don't think making w-a-s defaults depend on the debhelper compat level was
considered, and I think we don't yet have a clear agreement on -st vs -ast.

Hi!

Thanks for the quick reply Paride.

For the defaults, I see that '-a' is the most common option, so if the
decision is between -st vs -ast, seems to me it should be the latter?

I am not the decision maker here, but I would strongly vote for
coupling the behavior with Debhelper 14+ usage so that we can add
Lintian rules and Salsa-CI automation to suggest maintainers to run
`wrap-and-sort -ast` on packages that haven't done it. By coupling the
new defaults to a new Debhelper version we can keep wrap-and-sort
"backward compatible" and avoid annoying people on current versions by
having sudden changes in behavior. If changes apply only starting from
a specific version, the transition will be smoother.

Hi folks!

Can we now in 2025 agree that `wrap-and-sort -vast` is what we should
recommend new people joining Debian to use?

This proposal (--wrap-always, --short-indent, --trailing-comma) has
been open since 2018. If we can at least in principle agree that this
is best practice, the next discussion could be purely focused how to
best migrate to these new defaults.

I feel this question has become moot now that we have X-Style.

Chris

The X-Style is used by 'deputy reformat' only. This bug report is
about updating defaults in wrap-and-sort.

Conveniently, if we agree to default to 'ast' this wrap-and-sort and
deputy reformat will be fully aligned and there is minimal amount of
friction between tools.