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 [EMAIL PROTECTED] Note: this address is only intended for spam harvesters. Writing to it will get you added to my black list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
