Re: Bug#430023: please add gnu-fdisk-udeb and gnu-cfdisk-udeb
On Sun, Jul 15, 2007 at 03:26:26AM +0200, Frans Pop wrote:
> On Saturday 14 July 2007 20:15, Robert Millan wrote:
> > > - we already have parted-udeb, which I expect _does_ support GPT
> >
> > In my use case, the person who was installing had to call me because he
> > had to edit a GPT disk and didn't know how to handle parted. With my
> > proposed solution, I would have told him to "apt-install gnu-fdisk";
> > but instead I had to do all the partitioning myself.
>
> Aren't you confusing apt-install and anna-install here?
Sorry, I was.
> To be honest, I do not think that "some individual being unable to handle
> parted" is much of an argument. Especially as even using parted is only
> an last-ditch alternative to using partman. Partman is the partitioning
> tool of choice in the installer, and nothing else.
I don't remember well the details in why partman wasn't used. Anyway,
if there's a use case for having an fdisk implementation (and even for
installing it by default), one could think there's a use case for gnu-fdisk
in the repository.
> Now, maybe a case _could_ be made to drop the current fdisk udeb and
> switch to gnu-fdisk instead. However, that would mean that some serious
> comparison of both utils would need to be presented on the list.
I don't think it's feasible to consider that atm. Would be nice in the long
term, but as you say the package is just too new. I would rather wait and
see how it evolves.
In the short term, though, why not having both? Just keep the current fdisk
as the default, and let users apt-install (oops, anna-install ;-)) it as
an option.
> > But why is ncurses not acceptable? If it's a size issue, note that our
> > typical use case has at least one >2 TiB disk, so we should expect it
> > to be able to spare a few hundred kiBs of memory for ncurses (when user
> > wants to, not by default!)
>
> There are various reasons against:
> - the use-case presented here is WAY to weak to warrant supporting a new
> library for D-I
> - it would add a udeb to yet another library package, which would mean an
> added maintenance burden on its maintainer, and a quite significant added
> burden on the D-I release manager and on the Debian release managers
> (added complexity for migrations - especially complex transitions - to
> testing)
Ok.
> D-I and Debian release management are already a huge job. More udebs add
> considerably to the workload for both and thus have to be considered
> carefully.
> More udebs = more risk of random regressions = more risk of migration
> blockers = more risk of release delays = more stress and headaches.
I understand that you're handling a quite complex task here. Keep up the
good work :-)
--
Robert Millan
My spam trap is honeypot@aybabtu.com. Note: this address is only intended
for spam harvesters. Writing to it will get you added to my black list.
Reply to: