gpsd needs to ship packaging/deb/etc_default_gpsd as default instead of debian/gpsd.default

Well, yes and no.

I'd not ship the upstream version - dpkg-reconfigure just doesn't do anything.
But its true, that the USBAUTO option is missing in the default file. Seems that was added to the service at some point and went missing.

Ok, so lets add USBAUTO to ours then?

Unless you beat me to it I'll make this part of an MR once I have debugged the other open issues.

FYI - fix submitted as part of PR https://salsa.debian.org/debian-gps-team/pkg-gpsd/-/merge_requests/5

This bug was fixed in the package gpsd - 3.20-11

---------------
gpsd (3.20-11) unstable; urgency=medium

  [ Christian Ehrhardt ]
  * [232c8d73] d/rules: fix ubxtool to use python3 in the gpsd package (LP: #1878158)
    Signed-off-by: Christian Ehrhardt <email address hidden>

 -- Bernd Zeimetz <email address hidden> Tue, 12 May 2020 13:49:15 +0200

The auto-sync in groovy also included 3.20-8/3.20-9 which covers this issue here:

gpsd (3.20-10) unstable; urgency=medium

  [ Christian Ehrhardt ]
  * [7670b61e] exchange gpsd-client/tools content
  * [fb81a96a] examples also need to be in -clients instead of -tools then
  * [7f8d06a8] d/control[.in]: moving gpsctl still breaks gpsd-clients
    (<< 3.20-9) for upgraders never seeing the version in experimental

  [ Bernd Zeimetz ]
  * [b448fb08] Merge branch 'exchange-clients-and-tools' into 'master'
    exchange gpsd-client/tools content
    See merge request debian-gps-team/pkg-gpsd!6

 -- Bernd Zeimetz <email address hidden> Mon, 11 May 2020 14:40:08 +0200

gpsd (3.20-9) experimental; urgency=medium

  [ Christian Ehrhardt ]
  * [6a21e6bd] d/usr.sbin.gpsd: improve apparmor rules for PPS
               usage (LP: #1872175 LP: #1872178)
  * [c8b703b4] d/gpsd.default: add USBAUTO option (LP: #1873415)
  * [2fcf9754] split more uncommon tools to gpsd-tools (LP: #1872189)
  * [4a1454fb] d/control[.in]: have gpsd-tools depend on gpsd-clients
               as it extends on cgps
  * Move tools for local HW config into gpsd itself
    - [016cff82] move gpsctl to package gpsd
    - [b78132aa] d/control[.in]: move ubxtool and ntpshmmon to gpsd
  * python fixups for Lintian warnings
    - d/control[.in]: add python3 dependency to gpsd-dbg
    - d/rules: fix the py2/3 fixup applied post build
    - d/rules: let package gpsd be processed by dh_python3
    - d/control[.in]: gpsd needs python as depends

Therefore this is ready for an SRU to focal now

Waiting in Focal-unapproved since yesterday - FYI autopkgtest sniff tests are good as well in https://bileto.ubuntu.com/excuses/4047/focal.html

Please could you expand on the "Impact" section? I don't currently follow how this bug affects actual users.

There is also the conffile prompt to consider. What if a user installs this update, has a modified /etc/default/gpsd, but doesn't see the prompt? Will that system not receive this fix? For the SRU, would it be better to adjust /lib/systemd/system/gpsdctl@.service to handle a not-set USBAUTO variable? I'm unable to assess this because I don't yet understand the problem you're trying to fix.

> >=Groovy set default to true, but we will set false for Focal to not
   change behavior on SRU (adding the variable still is useful as people
   can modify it much more easily than adding - or knowing about - it)

Won't that cause an unwanted conffile prompt on future release upgrade?

Hi Robie.

> Won't that cause an unwanted conffile prompt on future release upgrade?

There will be no later future bad conffile prompt if the file isn't modified. This is because old/new conffile most likely will match the registered default checksum and therefore are upgraded without prompt. Instead it will change behavior "on upgrade" just as it already does on a F->G upgrade due to the new default being in Groovy.

> What if a user installs this update, has a modified /etc/default/gpsd, but doesn't see the prompt? Will that system not receive this fix?

yes, it is essentially a "fix of the conffile", therefore if someone skips the conffile update he will stay unfixed. Behavior will not change no matter if he "does update the conffile or not". In both cases USBAUTO will stay "off". It will just be more readable and usable if there is an explicit off setting in the conffile.

> For the SRU, would it be better to adjust /lib/systemd/system/gpsdctl@.service to handle a not-set USBAUTO variable

No as we'd further derive from how upstream, guides and other references will describe it.

> could you expand on the "Impact" section

Done

After discussion the "gain" for focal of this is low and the chance to get into trouble conffile change exists.
We agreed to take this bug out of the SRU.