On Sat, Nov 14, 2020 at 01:01:24AM +0000, Colin Watson wrote: > On Fri, Nov 13, 2020 at 04:11:43PM -0800, Brian C. Lane wrote: > > A big part of the trouble here was in the resize code, which we need to > > talk about. > > > > I'd like to get a 3.4 release with these patches out before the end of > > the year. Next year I want to drop the /r/ resize library again. It has > > no place in parted, isn't maintained, and isn't something I'd suggest > > anyone using. Filesystem code should be maintained by filesystem tools > > so if someone wants to move it into some other project that's fine with > > me but I strongly believe that it needs to be removed. > > > > We can talk about that in another thread though. > > I hope changing the subject line is close enough.
Nope, you need to break the in-reply-to chain as well. I've attempted to do that with this reply :) > Here are the packages that depend on the resize library in Debian (we > have it in a separate .deb, which has the convenient side-effect of > making it easy to spot who's using it): > > fatresize (https://github.com/ya-mouse/fatresize) > gparted (https://gparted.org) > libblockdev-fs2 (https://github.com/storaged-project/libblockdev) > > All three of these are active in the sense of having had commits in the > last year, so if you're working on removing the library it would be good > to explicitly contact the maintainers of those projects so that they > have due warning and can work out some kind of alternative, perhaps in > collaboration with each other. (I haven't checked in any other > distributions; perhaps there are other things elsewhere.) Thanks for tracking that down. I'd like to figure out a nice way to deprecate them, I'm not sure if that's been done with a parted API before. As far as a timeframe goes, given the glacial pace of parted releases, I'm thinking a 4.0 release next December would be a good time to remove them. This leaves plenty of time to adjust. Brian -- Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart
