gconf removal for buster premature?

[Yavor Doganov]

Hi,

While working on porting the zapping package to GSettings, it occurred
to me that your plan to ship buster without gconf is a bit premature
because stable users will not have their settings migrated.

A dist-upgrade run will almost certainly remove the gconf2 package and
any application-specific data migration code that relies on
gsettings-data-convert will fail.  At the time users run the upgraded
GSettings-based version of their program, there will be no
gsettings-data-convert binary around to spawn in order to convert
their old settings.  While some obscure apps (like zapping, perhaps)
can be sacrificed, there are some important packages with rich
functionality and gazillion of settings (think of gnucash, which
migrated recently).

In any event, it is not nice to leave users out in the cold.

Let me suggest the following:

  * Ship src:gconf in buster, possibly a stripped-down version enough
    to ensure that gsettings-data-convert works.  (As an idea, you can
    just remove all binary packages but gconf2, install the library as
    private and make the tool link with it.  I'd be happy to help if
    that seems a lot of work.)
    
  * Keep the bugs you filed for all rdeps at severity serious, to
    ensure they are fixed in buster so that you can finally remove
    src:gconf in bullseye.

  * Since gconf2 (the package providing gsettings-data-convert) may
    still be removed during upgrades (very likely as all packages in
    buster will drop the dependency), all GConf-based apps in stretch
    that were migrated to GSettings should have an explicit dependency
    on gconf2 (or the new binary package providing a working
    gsettings-data-convert).  Bugs should be filed for these packages,
    to add the additional dependency which ensures the migration.
    (You can deduce the list of packages by comparing the rdeps in
    stretch vs buster.)

  * Ideally, the previous item can be done semi-automatically, by
    modifying debhelper and scheduling binNMUs.  I don't know enough
    about dh_gconf so I don't know if that's possible.  With a right
    fix in debhelper, the release team can just schedule binNMUs for
    the affected packages so that the (migrated during the buster
    development cycle) GSettings-based packages pick the new
    dependency for the sake of data migration.

WDYT?