With the change in 3.017 to drop "Priority: optional" I found an
interesting case:

Given the following situation: a debian/control file …
- - with Standards-Version: 4.7.2
- - without a Priority field (already removed when dpkg declared
  "optional" the default)

cme modify dpkg-control -save

will (reformat d/control if necessary and) add "Priority: optional"
to it.

When I then call

cme modify dpkg-control source 'Standards-Version="4.7.3"'

the S-V is correctly bumped -- and "Priority: optional" is removed
again.

(Commands taken from dpt-fixup in pkg-perl-tools.)

That's not really what I want, especially not with git commits after
each change :)


I think I see the point of making the removal of Priority conditional
on the Standards-Version; on the other hand:
- - AFAIR, `cme modify dpkg-control -save' has only reformatted
  d/control and never added/removed any fields; or I don't remember
  or I never hit such a situation;
- - I would also argue that "Priority: optional" was obsolete with dpkg 1.22.13
  (January 2025), it just took some time until this was written down
  in policy.


Not sure what the best way out is …


Cheers,
gregor
-----BEGIN PGP SIGNATURE-----

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmluX4JfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgaVrhAAoszbHb7cTmVCsa9m316qzZMM22y0egxBSoJb2w2nq00rvD/00Vh6OutS
aYloVfIDBhyaFyxDFWdYr6kAbK2p4Qhx1mHlCBUC6zHRDu60bAPBWkFAj8UZe+hT
65vItwXDVBhBsf8GtK/W1wYGShLVjdyE5SIYfcg1uwUHonTQOld88uI9clrMslTf
v5tJMcAIb+uP10Wuv7SAci9DStUSwKAag2fdRxFjDNwDvWP1KU4l4YHgz5rlWD2S
xFKqa/Hogzyww2zr68Xth0KIcg2yfPmq7MDRQlU2jb9QT/bmNInP2JsKQDZGYXIA
dphLJr9EPnYm8gX0XLIOYjSFTSTy9SbXNRfEk8tuGO7jTSqzy8O9mEmSN1PomNqK
FxM0rSwqd/TcyrEYNBtCrzSFEDfLsUjsdAQDY9a2po0Te8CLLrTHakirHGbU5g6d
9ZSIbfN9e5PRNPRR3E4QvIaXaPxZ4b7RZkjlC3XnSWMMlIMi6Nar5SORy8mno9Qr
MQzYyswzeyYd3dYRH+df21mHZv2NAVOr8NcgosxHgm3Yg4uCXdlpsTlICfbNGatn
qe2CbKFNr4OBol2SB7LxtAwf4mACslVcXDSIOL7s2NffrxeHto5Uxs7Yn5IyM2sh
76FmxoEA6tZnTiV3OKoQsODzprI6CQYJYl/vy/+Ts72eBoAp3aw=
=P5pY
-----END PGP SIGNATURE-----

With libconfig-model-dpkg-perl 3.106 we had:
- Priority upstream-default = optional no matter the value with Standard-Version
- a bug which wrote the value of Priority field if it was set (by user or because it was in control file). Hence this field would not be added, and not be removed (hence the bug files by Andreas)

With 3.017:
- a bug fix to not write a value that is identical to upstream_default value
- a conditional setup where upstream_default is optional for Std-version >= 4.7.3  and default is optional for Std-version < 4.7.3

The second change is what writes back Priority/optional field with Std-version = 4.7.2.
Thus cme would drop Priority/optional field in any case.

However, cme cannot decide if  user wants to reformat without changing anything (dpt-fixup) or want to drop unnecessary fields (Andreas' bug). So you may have case where Priority/optional is dropped when running «cme modify dpkg-control -save».

What do you prefer ?

All the best

PS: you can use «cme run update-standards-version» instead of these lines:

if ! grep -qF "Standards-Version: 4.7.3" debian/control; then
 	cme modify dpkg-control source 'Standards-Version="4.7.3"'
 	not_is_dirty || git commit -a -m 'Declare compliance with Debian Policy 4.7.3.' || true
 fi

you will get the same change, including the git commit

Ack, thanks.
anything (no modifications requested), and that `cme fix
dpkg-control` (as used by Andreas, and also by dpt-fixup later) is
supposed to change/fix things. Looking at cme(1p) still makes me
believe that this is not a completely stupid assumption :)

Taking a step back: The idea of running `cme modify dpkg-control -save`
early is to have the (pure) reformatting in a separate git commit
before making any specific changes (also as atomic as possible), and
I don't know what's the best way to achieve this. `cme fix` should of
course drop "Priority: optional" as requested by Andreas; if `cme
modify` without any arguments can be made to act no-changing that
would be great, otherwise a `cme reformat` might be an idea? Or `cme
run reformat`?

Oh, nice, thank you!


Cheers,
gregor

- update format and semantically equivalent changes so you get the same behavior from your application. The change can include:
  - dropping redundant field/value like Priority/optional
  - dripping obsolete fields
  - adding default values
  - migrating fields (i.e. when a field is deprecated and replaced by another one)
- a warning requires a user decision to accept or not the change (for instance, one should apply blindly a Standard-Version upgrade)

I may have to change the wording of cme doc ...

ack
- config tree load data as required (the read routines are called by the tree)
- config tree performs update, re-ordering and other "minor" changes
- then data is written back by the tree when needed

Disabling modification would require quite a lot of change in Config::Model core and I can't extract the read/write routines, the config tree is the backbone of cme and the read/write routine are attached to this backbone.

All the best

For "modify" or for "fix"? Or, put differently, what's the difference
between them in your idea?

No hurry, I understand this is complicated, and it's just a minor
thing.


For my workflow / for dpt-fixup, I thought about:
- replacing `cme modify dpkg-control -save` for formatting with
   either `wrap-and-sort -ast` or
   `debputy reformat --style black --no-linter-exit-code`
   They both seem to have agreed on a common format, just I'm not
   happy with parts of it:
   + putting ${subst:Vars} at the bpttom of Depends
   + putting some build dependencies (like debhelper) before all
     others.
- for the time being, bumping the S-V (with sed etc.) before the call
   to `cme modify dpkg-control -save`, then the latter shouldn't add a
   removed Priority:optional back.


Cheers,
gregor

For "modify"

With "fix", cme decides what needs to be modified to fix warnings. For dpkg, this
depends on the content of dpkg model.

With "modify", the modification is decided by user. This command is intended to
be used with arguments to actually modify dpkg files. For instance:

  cme modify dpkg-control source Maintainer="Foo <foo@debian.org>"

The fact that some minor modification like reformat, migration of deprecated
values (e.g. Priority extra changed to optional) is a side effect.

Another less known command is "cme migrate" which is equivalent to "cme modify
-save" (barring a bug which will be fixed with cme 1.044)
- by default priority is unchanged (no default value, no upstream default
value)
- when Standard-Version is >= 4.7.3 , a warning is emitted when Priority is
set to optional with a fix to remove this value.

I don't like this option because it may be confusing for "cme edit dpkg"
users: the GUI will not show any hint on Priority's default value and user
will get a warning when Priority is set to "optional" even if it is a legal
value. IMHO, a warning should not be issued for a harmless value.

Or you can do the same with :

cme modify dpkg-control source StandardsVersion=4.7.3

or

cme run update-standards-version

HTH

Thanks for taking the time to explain!

Agreed.

Well yes, but this also reformats d/control, which I wanted to keep
in a separate step :)


Cheers,
gregor