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 <[email protected]>
sra-sdk (U)

Alastair McKinstry <[email protected]>
cctools

Alessio Treglia <[email protected]>
mp3fs (U)

Alex Myczko <[email protected]>
xrdp (U)

Aloïs Micard <[email protected]>
wit

Anders Kaseorg <[email protected]>
openafs (U)

Andrea Capriotti <capriott@debian.

Hi,

On Tue, 13 Aug 2024 20:02:48 +0200, Chris Hofstaedtler <[email protected]>
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)

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)

On Wed, 21 Aug 2024 23:24:23 +0200, Chris Hofstaedtler <[email protected]>
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)

Hi,

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

On Wed, Aug 21, 2024 at 11:24 PM Chris Hofstaedtler <[email protected]> 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)

Hi,

* László Böszörményi (GCS) <[email protected]> [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 <[email protected]> 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)

On Sun, Aug 25, 2024 at 11:14 PM Chris Hofstaedtler <[email protected]> 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)

On Thu, Aug 29, 2024 at 2:56 PM László Böszörményi (GCS) <[email protected]> wrote:

On Sun, Aug 25, 2024 at 11:14 PM Chris Hofstaedtler <[email protected]> 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)

* László Böszörményi (GCS) <[email protected]> [240829 20:55]:

On Sun, Aug 25, 2024 at 11:14 PM Chris Hofstaedtler <[email protected]> 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)