• Intent to MBF: move from fuse to fuse3

    From Chris Hofstaedtler@21:1/5 to All on Tue Aug 13 20:30:01 2024
    Fellow developers,

    fuse (2.x) is long obsolete, yet we still have a long tail of packages (Build-)Depending on it. Given fuse and fuse3 are not coinstallable,
    IMO we should get packages off fuse.

    Below is my proposed MBF wording, and a dd-list.

    Chris

    ---

    Subject: SOURCE: move from fuse to fuse3

    Source: SOURCE
    Version: VERSION
    Severity: normal

    Dear Maintainer,

    your package currently (Build-)Depends on fuse - that is
    fuse 2.x. A newer version of fuse, fuse3, is available
    since at least buster.

    fuse (2.x) and fuse3 are not co-installable. On a typical
    Debian Desktop install, fuse3 is installed, and fuse 2.x
    cannot be installed.

    This effect can be observed in the popcon graphs:
    https://qa.debian.org/popcon.php?package=fuse
    https://qa.debian.org/popcon.php?package=fuse3

    Please migrate your package to fuse3, so our users can
    actually use it, and we can remove fuse 2.x in forky.

    ---

    Aaron M. Ucko <ucko@debian.org>
    sra-sdk (U)

    Alastair McKinstry <mckinstry@debian.org>
    cctools

    Alessio Treglia <alessio@debian.org>
    mp3fs (U)

    Alex Myczko <tar@debian.org>
    xrdp (U)

    Aloïs Micard <creekorful@debian.org>
    wit

    Anders Kaseorg <andersk@mit.edu>
    openafs (U)

    Andrea Capriotti <capriott@debian.
  • From Stephen Kitt@21:1/5 to All on Thu Aug 15 11:10:01 2024
    Hi,

    On Tue, 13 Aug 2024 20:02:48 +0200, Chris Hofstaedtler <zeha@debian.org>
    wrote:
    fuse (2.x) is long obsolete, yet we still have a long tail of packages (Build-)Depending on it. Given fuse and fuse3 are not coinstallable,
    IMO we should get packages off fuse.

    Below is my proposed MBF wording, and a dd-list.

    Chris

    ---

    Subject: SOURCE: move from fuse to fuse3

    Source: SOURCE
    Version: VERSION
    Severity: normal

    Dear Maintainer,

    your package currently (Build-)Depends on fuse - that is
    fuse 2.x. A newer version of fuse, fuse3, is available
    since at least buster.

    fuse (2.x) and fuse3 are not co-installable. On a typical
    Debian Desktop install, fuse3 is installed, and fuse 2.x
    cannot be installed.

    This effect can be observed in the popcon graphs:
    https://qa.debian.org/popcon.php?package=fuse
    https://qa.debian.org/popcon.php?package=fuse3

    Please migrate your package to fuse3, so our users can
    actually use it, and we can remove fuse 2.x in forky.

    There are two separate concerns here: the fuse binary package used to provide fusermount etc., and the library used by FUSE programs.

    fuse and fuse3 are not co-installable, but that only affects fusermount and
    co. libfuse2 and libfuse3 are co-installable.

    This means that packages build-depending on libfuse-dev can produce binary packages usable with fuse3; see for example loggedfs’s debian/control:

    […]
    Build-Depends:
    debhelper-compat (= 13),
    libeasyloggingpp-dev,
    libfuse-dev,
    libpcre2-dev,
    libxml2-dev,
    […]
    Depends: fuse (<< 3) | fuse3 (>= 3.10.1-3), ${misc:Depends}, ${shlibs:Depends}


    I have a number of libfuse2-based packages running with fuse3, everything
    works fine.

    This doesn’t mean that the MBF isn’t warranted — migrating off of fuse would
    be a good thing. There is some work involved however; see https://github.com/libfuse/libfuse/releases/tag/fuse-3.0.0 for details
    (perhaps the MBF message could include that).
    https://bugs.debian.org/918984 and
    https://bugs.debian.org/927291 are also relevant (although as mentioned
    above, the latter isn’t a concern in practice).

    Regards,

    Stephen

    -----BEGIN PGP SIGNATURE-----

    iQIzBAEBCgAdFiEEnPVX/hPLkMoq7x0ggNMC9Yhtg5wFAma9w/oACgkQgNMC9Yht g5xe0hAAjeG+OnsLt8PbtPzpmgtesNBimUC2YLKAYa2FOVedEk1j+QzBWND7s78M 77uDe2cARR2jndWEppNjvsrTQxlEfvl00r5qVtyrqALsH2ma5ipaBqXiBcaMz97a TLIPCoZ54CVrr3N/CEBrQUPvgLynQr+ltgZe+WPwbdGa8O/9GNbePGkxt1U8bpju ZUDV+UreuLcE6EUr/aKkum+yYXew3e9j2MsBLgj7GyqewBRzO8TcAxsueXxw6BAr gpTujEN5SBEatJV9WrRJOefoP+UyNWyr9Mlk4qoKsgd6uKX5Pp3TOzwqxagVZ7dO ohNJXJ8RB2/CC0VXwRhy5Z+UczyID3bEAg0AYv/Rycr3cSpAawM39dP9lxmM8W+M 0+t09ktLrXSDhGHWutly1Utx42ttCTm4og9Mam0XYrr6vIpPwbZshEDqgmR15P5a 5V0b4Rhrg0NwcSSieQ7GH5C3/6UIKU0SOMOH7X3vWZ4qi6V+VVELDQuaWrrMaaL/ k4jh+YHli7mjhVva/XteGRJMN3mH852JcCwlrFup7COhTHCmV/PudZjSSKsa+Hne IIQCKkbHeTTwnEod2S0qEngTocwk8WIdGaL6ynsc7uvKDRcdNVgs89JeHFouzXQL W2qVw6o1hVD3fa6UBzpAUV4VJvqulCyyo0PcAllsRuZ8sJUb5rU=
    =spxx
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Chris Hofstaedtler@21:1/5 to All on Wed Aug 21 23:30:01 2024
    Stephen,
    and everyone else who pointed out that coinstallability is a
    non-issue - thanks!

    About the additional work in fuse/fuse3, #918984 and #927291, I
    wonder if they are relevant to the libfuse consumers. Anyway, if we
    believe fuse3 works just fine with libfuse2-* consumers, then it
    seems like we should fix the package relationships between fuse3 and
    fuse.
    I'll followup in #927291 with suggestions.


    Updated MBF text proposal:

    Subject: SOURCE: move from fuse to fuse3

    Source: SOURCE
    Version: VERSION
    Severity: normal

    Dear Maintainer,

    your package currently (Build-)Depends on fuse - that is fuse 2.x.
    A newer version of fuse, fuse3, is available since at least
    buster.

    Please migrate your package to fuse3, which is actively
    maintained. It would be great if we could remove fuse 2.x in
    the forky development cycle.

    If you cannot migrate yet, please at least update your Depends:
    line. If you currently have:
    Depends: fuse
    please update that to:
    Depends: fuse3 (>= 3.10.1-3) | fuse (<< 3)

    This allows mount.fuse and fusermount to be provided by fuse3,
    which is what the majority of new installs already have [1].

    [1] compare https://qa.debian.org/popcon.php?package=fuse
    and https://qa.debian.org/popcon.php?package=fuse3

    Does that sound good?

    Chris

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stephen Kitt@21:1/5 to All on Thu Aug 22 23:30:01 2024
    On Wed, 21 Aug 2024 23:24:23 +0200, Chris Hofstaedtler <zeha@debian.org>
    wrote:
    Stephen,
    and everyone else who pointed out that coinstallability is a
    non-issue - thanks!

    You’re welcome!

    About the additional work in fuse/fuse3, #918984 and #927291, I
    wonder if they are relevant to the libfuse consumers. Anyway, if we
    believe fuse3 works just fine with libfuse2-* consumers, then it
    seems like we should fix the package relationships between fuse3 and
    fuse.
    I'll followup in #927291 with suggestions.

    Your suggestion there seems fine to me. I’d love to hear Laszlo’s thoughts on
    the topic too!

    Updated MBF text proposal:

    Subject: SOURCE: move from fuse to fuse3

    Source: SOURCE
    Version: VERSION
    Severity: normal

    Dear Maintainer,

    your package currently (Build-)Depends on fuse - that is fuse 2.x.
    A newer version of fuse, fuse3, is available since at least
    buster.

    Please migrate your package to fuse3, which is actively
    maintained. It would be great if we could remove fuse 2.x in
    the forky development cycle.

    I would add a reference to https://github.com/libfuse/libfuse/releases/tag/fuse-3.0.0 (which isn’t a great migration guide but does list all the significant changes people
    working on this will encounter).

    If you cannot migrate yet, please at least update your Depends:
    line. If you currently have:
    Depends: fuse
    please update that to:
    Depends: fuse3 (>= 3.10.1-3) | fuse (<< 3)

    This allows mount.fuse and fusermount to be provided by fuse3,
    which is what the majority of new installs already have [1].

    [1] compare https://qa.debian.org/popcon.php?package=fuse
    and https://qa.debian.org/popcon.php?package=fuse3

    Does that sound good?

    It does to me, with the added reference above!

    Regards,

    Stephen

    -----BEGIN PGP SIGNATURE-----

    iQIzBAEBCgAdFiEEnPVX/hPLkMoq7x0ggNMC9Yhtg5wFAmbHq6YACgkQgNMC9Yht g5zy+g/+OTd6d8cLgmf0+QksDQR5215HqCp1pJWSx8pfe5mCktPwhhtFyjUb+VU9 C/v6mA/Uxi0vVDl5FK2QVSDR3xwxWrKct4HqY/ql2llZCzmqA5YLGBgdMe5TLDWx NPHZRTvkKj8vC19r/Fi9A6fJmNM9ULL0WT65S1OmLXD3y9ajqCdKca6/cCeoPbRW bz4tZ+apEeutnfvacKNWuVJd1coVMO+qKVDxfl4O9jWlFsfAbkiJecDj28ZBJj3a /7bK6yRj+b6pr5wGFNqSTp4JLUvqBuAm7jZhQlEiid0ahxnzIdbrUmPF35LslQ8y rgLs1mkr9Ah7MAfLuLT+sPRk1szO2QK9T640b8amehgPIg8gk77FR7IJ0rPh4vir FZeKBdpq6LIrRd9NRBzIXLEa/RzDta745Z3CzwrVhaoLkaSRX8R4c/xXl+AzXvp/ ijEiMEzTsXD0Fj9xxu1qfJbl+voDTQKDAJbUv0bvzL5vB0oqHgDeWxuwwIIHvVh+ Un6f3kNufOgKg+Tp5+7qXtY83h8vSlJogkKgVn9b+USDwxUAhc7ti+t4o8qzx493 9ag+Y+Tt8XInt0SiImzw4gJo2ysFv/64D2m+cdbHQssRrZRdy7rZ10RgAc1uzR3S L+lmGNKa9wCy7erXh3pJceMjTrLa6mkVTm9skebvXoxiHbLM1bY=
    =JpeI
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?B?TMOhc3psw7MgQsO2c3rDtnJtw@21:1/5 to zeha@debian.org on Sun Aug 25 18:40:01 2024
    Hi,

    Thanks for adding me, I can't follow -devel.

    On Wed, Aug 21, 2024 at 11:24 PM Chris Hofstaedtler <zeha@debian.org> wrote:
    Updated MBF text proposal:
    [...]
    Does that sound good?
    This sounds right to me, except that the fuse package should be
    removed in the Trixie release already. It was obsoleted more than five
    years ago and it's time to move on. The libfuse2 package might remain,
    but dependent packages had enough time to migrate already.
    Unfortunately it is known in other distributions as well [1] that for
    some reason (laziness probably) projects don't migrate to fuse3.

    Regards,
    Laszlo/GCS
    [1] https://github.com/NixOS/nixpkgs/issues/150502#issuecomment-2017295190

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Chris Hofstaedtler@21:1/5 to All on Sun Aug 25 23:20:01 2024
    Hi,

    * László Böszörményi (GCS) <gcs@debian.org> [240825 18:30]:
    Thanks for adding me, I can't follow -devel.

    Sorry for not thinking about that earlier

    On Wed, Aug 21, 2024 at 11:24 PM Chris Hofstaedtler <zeha@debian.org> wrote:
    Updated MBF text proposal:
    [...]
    Does that sound good?
    This sounds right to me, except that the fuse package should be
    removed in the Trixie release already. It was obsoleted more than five
    years ago and it's time to move on.

    Yeah, I agree. Do you want to upload a new src:fuse package dropping
    the fuse binary package?
    fuse3 already Provides: fuse, so that should be fine.

    The libfuse2 package might remain,
    but dependent packages had enough time to migrate already.
    Unfortunately it is known in other distributions as well [1] that for
    some reason (laziness probably) projects don't migrate to fuse3.

    Ack, for now libfuse2(-dev) should stay :-(

    Regards,
    Laszlo/GCS

    Best,
    Chris

    [1] https://github.com/NixOS/nixpkgs/issues/150502#issuecomment-2017295190

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?B?TMOhc3psw7MgQsO2c3rDtnJtw@21:1/5 to zeha@debian.org on Thu Aug 29 21:00:01 2024
    On Sun, Aug 25, 2024 at 11:14 PM Chris Hofstaedtler <zeha@debian.org> wrote:
    Yeah, I agree. Do you want to upload a new src:fuse package dropping
    the fuse binary package?
    fuse3 already Provides: fuse, so that should be fine.
    The question is, how many dependent packages use the binaries from
    the fuse package or just depend on it. Sure, fuse3 provides fuse but
    the names of the binaries are different. For example scripts need to
    update fusermount call to fusermount3 call. As such, it might be
    better to ping maintainers of those packages about dropping the fuse
    binary for testing their packages first. Then after a month actually
    drop it.
    I was informed that debian-edu and grub-mount-udeb still use
    fuse-udeb, but in Trixie packages I don't see that anymore. I can drop
    that as well in a month.
    How do these sound there?

    Cheers,
    Laszlo/GCS

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Jeremy_B=C3=ADcha?=@21:1/5 to gcs@debian.org on Thu Aug 29 21:30:01 2024
    On Thu, Aug 29, 2024 at 2:56 PM László Böszörményi (GCS) <gcs@debian.org> wrote:
    On Sun, Aug 25, 2024 at 11:14 PM Chris Hofstaedtler <zeha@debian.org> wrote:
    Yeah, I agree. Do you want to upload a new src:fuse package dropping
    the fuse binary package?
    fuse3 already Provides: fuse, so that should be fine.
    The question is, how many dependent packages use the binaries from
    the fuse package or just depend on it. Sure, fuse3 provides fuse but
    the names of the binaries are different. For example scripts need to
    update fusermount call to fusermount3 call. As such, it might be
    better to ping maintainers of those packages about dropping the fuse
    binary for testing their packages first. Then after a month actually
    drop it.

    On the other hand, I've read reports of people breaking their systems
    because they install fuse which uninstalls fuse3 (perhaps because they
    are trying to install libfuse2 to get AppImages to work or perhaps
    because fuse is a generic name). So I'd rather we got rid of the old
    fuse binary package quicker. https://launchpad.net/bugs/1978310

    Although I guess it would be a lot of work to fix that for Debian 12. :(

    Thank you,
    Jeremy Bícha

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Chris Hofstaedtler@21:1/5 to All on Mon Sep 9 01:00:02 2024
    * László Böszörményi (GCS) <gcs@debian.org> [240829 20:55]:
    On Sun, Aug 25, 2024 at 11:14 PM Chris Hofstaedtler <zeha@debian.org> wrote:
    Yeah, I agree. Do you want to upload a new src:fuse package dropping
    the fuse binary package?
    fuse3 already Provides: fuse, so that should be fine.
    The question is, how many dependent packages use the binaries from
    the fuse package or just depend on it.

    A handful. But given the Provides: and the compat symlinks, packages
    depending on fuse today do not need to change.

    Sure, fuse3 provides fuse but
    the names of the binaries are different. For example scripts need to
    update fusermount call to fusermount3 call.

    fuse3 already provides the old names as symlinks. The options of
    fusermount <> fusermount3 and mount.fuse <> mount.fuse3 are the
    same.

    As such, it might be
    better to ping maintainers of those packages about dropping the fuse
    binary for testing their packages first. Then after a month actually
    drop it.
    I was informed that debian-edu and grub-mount-udeb still use
    fuse-udeb, but in Trixie packages I don't see that anymore. I can drop
    that as well in a month.

    Yeah, this is resolved.

    How do these sound there?

    I think you can drop both the udeb and the "fuse" package
    immediately.

    Chris

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)