[parted-devel] next to master; making a beta release soon; plans

[Curtis Gedak]

Jim Meyering wrote:
> Curtis Gedak wrote:
>
>   
>> Jim Meyering wrote:
>>     
>>> Curtis Gedak wrote:
>>>
>>>       
>>>> GParted uses the library libparted when resizing FAT16/32 file systems.
>>>>
>>>>         
>>> Good.  Then I will remove the command-line "resize" option
>>> and merely leave the library code.
>>>
>>>       
>> Hi Jim,
>>     
>
> Hi Curtis,
>
>   
>> After some more thinking (and researching), I believe a better
>> solution is available.  My thoughts are that is better to keep the
>> file system specific tools together similar to what has been done with
>> with e2fsprogs.  In this case dosfstools might have a new fatresize
>> command added to the package.
>>
>> To get to this state the following steps might be taken:
>>
>> 1)  Create a fatresize command
>>
>> This would involve extracting the FAT16/32 file system resizing code
>> from parted and creating a stand alone command.  As you pointed out
>> earlier, there is a fatresize project on SourceForge that appears to
>> have done this already.  This project has seen recent development
>> activity as seen in this link:
>>
>> http://fatresize.git.sourceforge.net/git/gitweb.cgi?p=fatresize/fatresize;a=summary
>>
>> Perhaps the fatresize project team might be contacted to confirm if
>> their intent is to continue maintaining a stand alone fatresize
>> command _IF_ the FAT resizing code is removed from the parted project.
>>     
>
> That would be a great solution.
> I'd appreciate it if you would contact them and ask about it.
>   

I will look into contacting the fatresize project regarding this question.

>   
>> 2)  Remove the FAT16/32 file system resizing code from the parted project
>>
>> This would clean up the parted code to better align with the parted
>> project vision (which I believe is to focus on partition editing, and
>> to move away from file system manipulation).
>>
>> My concern with removing the resize command from parted, but leaving
>> the resizing code accessible to the parted library, is that it would
>> make it more difficult to maintain this code.
>>     
>
> An hour ago, I posted a 4-change-set series that started with this comment:
> [Unfortunately, it's big enough that it requires moderator approval]
>
>     Subject: planned UI removals
>     Date: Fri, 18 Sep 2009 17:33:51 +0200
>
>     Here's the start of the UI removals I mentioned recently.
>     It removes all FS-aware sub-commands except resize.
>     We have to retain resize at least for FAT16/32, since
>     there seems to be no other unix-oriented tool that can do that.
>     I'm leaving the resize command in the UI to ease shell-based testing.
>
>     This series isn't complete, since it still allows resizing of
>     file systems of types other than FAT16/32.  That's next.
>     I'll add a few tests of resizing, along the way.
>
>     I'll push these or something close on Monday.
>   

I think it is a good idea to keep the resize FAT16/32 file system code 
in parted for at least a while longer (perhaps even up to a year or 
more).  That way it will provide some overlap time between when the 
fatresize project contains the updated code from parted, and when 
dosfstools might include the fatresize command.  This will also provide 
various distributions time to include such code in the respective 
updated packages.

>   
>> The parted project includes many tests to exercise the code, which I
>> heartily applaud.  Removing the command line resize command would make
>> it more difficult to exercise the library resize code.
>>
>>
>> 3)  Include the fatresize command with the dosfstools project/package.
>>
>> Recently there has been some activity with the dosfstools package as
>> can be seen in the following link:
>>
>> http://www.daniel-baumann.ch/software/dosfstools/
>>
>> Perhaps the current maintainer of the dosfstools package could be
>> contacted to consider including the fatresize command in the
>> dosfstools package.
>>
>>
>> In conclusion I think a better long term solution would be migrate the
>> FAT resize code out of the parted project into it's own project.  To
>>     
>
> I agree completely.
>
>   
>> do this successfully will require that someone is committed to
>> maintaining the fatresize command after the functionality is removed
>> from parted.  We can hope that this is already happening.  :-)
>>