Hello Nick! On 9/26/21 16:29, Nick Black wrote:I'd be delighted to support them -- as in, I am honestly eager to add ATARI support; that sounds awesome -- I just need some way to test the implementations, either via someone running it on the environment, or getting access to such a machine.There are emulators available for Atari such as Aranym. And emulators available for Amiga such as fs-uae. FWIW, parted should contain everything needed to be able to implement your own support for these partition tables.I think it makes little sense to not use libparted as it already supports all common and less common partition types and reimplementing everything that libparted makes little sense to me.parted did not have ZFS support when I embarked on this project (it appears to have it now). i would not be opposed to leveraging libparted if it presents a definite advantage; supporting more partition types, so long as it exposes an API i can easily work with, would be such an advantage.Well, using a missing feature in the past against parted that is present there is not such a good argument against using it, to be honest.i do note that libparted2 is 621K in the archive, whereas growlight itself is only 555K. it is of course possible that all that weight is desirable functionality.I think 70k more disk space is not really a concern.with that said, i would *still want to test on the target environment*, to make sure i'm using libparted correctly there. so that necessity remains.I thought you didn't depend on libparted?would this allay your concerns?No, not really. I consider a partitioning tool to be too important to be replaced by an unproven solution.
Growlight seems like an adequate tool for Debian expert option as it has potential to enable additional flexibility and extensibility for file system options which may not offered in the current set of Parted utilities. For instance, the current Growlight string/option 'enter filesystem name' could be re-implemented, with a couple lines of code, into something like 'enter plugin override'
< https://metztli.it/bullseye/gl/gl-reiser4-plugin-override.png >
etc., for other filesystems.
Also Growlight may reduce at least a subset of UDEB modules
needed for each file system supported by Debian, thus reducing
complexity. For instance, it was relatively straightforward to add
support for reiser4 -- as compared to initial efforts developing
substantial code for a partman-[filesystem] UDEB module.
< https://metztli.it/bullseye/gl/growlight-reiser4.png >
In other words, even if there is no compelling reason to update d-i at the moment, Growlight has potential to decrease complexity in the long run.
Just a point of view from an outsider, of course, I do not want anyone 'to have a cow' for refusing to potentially move away from their place of comfort and/or entertaining a perspective that may be considered 'taboo.'
Best Professional Regards.
--
