Hi Laszlo, On Sun, Nov 05, 2023 at 02:19:18PM +0100, László Böszörményi (GCS) wrote: > I think distributions should do the opposite, somehow enforce > projects to migrate to the new, supported FUSE version. Basically it > is deprecated since 2018 and as 2024 is approaching it means for six > years.
I'm with you on this in principle. It is not going to happen by itself though. I think you could help the situation by improving communication about it. build-rdeps shows 88 rdeps for libfuse-dev. Let me propose some options: * You could MBF those 88 rdeps with a normal bug asking them to move to fuse3. Chances are that a small fraction only needs to have their dependency updated. In other cases, you make the maintainer aware that there is a need for action. * You could reassign the package name libfuse-dev to fuse3 and rename the current libfuse-dev to libfuse2-dev. If you want to do this, I suggest that libfuse-dev starts providing libfuse2-dev now and that the MBF mentions this move. Then for each of those 88 packages it'll build with fuse3 or the maintainer has to make a choice between porting and changing the dependency to libfuse2-dev. While this may annoy some, it also gets people to think about the problem. After a while (say two months) you could move libfuse-dev to fuse3 and bump the remaining bugs to rc. Since there was a warning and lots of time, there won't be much grief. * I think given the rdeps it would be good to include fuse 2.x in trixie. But you could still announce that fuse 2.x is being deleted after trixie. If you do that now in that MBF, it'll serve as another clue about what to do. People won't be surprised when you file the RM bug for fuse in the forky cycle. This is just a rough sketch. It probably needs to go through a d-devel discussion (since it is a MBF), but doing this is relatively limited work on your end with the prospect of getting rid of fuse 2.x within two years. In particular, publishing such a schedule helps others plan and communicate the porting need to upstreams. > Yes, it makes upstreams more easily staying with the FUSE 2 API. > Making the switch to the FUSE 3 API more difficult. But OK, let it go. > I'm preparing the upload. Thank you. Helmut
