[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: partman, growlight, discoverable partitions, and fun

On 9/27/21 4:01 AM, John Paul Adrian Glaubitz wrote:
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.


Jose R R
Download Metztli Reiser4: Debian Buster w/ Linux 5.13.14 AMD64
feats ZSTD compression https://sf.net/projects/metztli-reiser4/
or SFRN 5.1.3, Metztli Reiser5 https://sf.net/projects/debian-reiser4/

Official current Reiser4 resources: https://reiser4.wiki.kernel.org/

Reply to: