On Monday, 19 January 2026 19:01:37 Central European Standard Time you wrote: > I thought that `cme modify dpkg-control -save` doesn't change > 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 :)
The idea I had was more: - 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 ... > 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), ack > 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`? I'll have to think about it. That would be quite difficult as cme is designed this way: - 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
