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? 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. We have other limitations in D-I that could be added by adding a whole range of tools (either by default or optional). Some basic rules for D-I development are: keep it simple and lean; no duplication; no frills. That translates to: if we already have parted to cover your use case, we don't want nor need gnu-*fdisk. 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. This would of course mean that for some architectures it _would_ be loaded by default, so such an analysis would have to include size and memory differences. However, the fact that the package is relatively new (not even included in Etch) and its dependency on libparted IMO make a switch unlikely, at least in the short term. > > - the new udebs conflict with the fdisk/cfdisk udebs, but udpkg does > > not support Conflicts: (design decision) > > We can rename the binaries and drop the Conflicts. If we rename fdisk > to fdisk-gnu rather than gnu-fdisk, it'll even make shell expansion > work. That would work, but we first need to determine that we actually want the gnu-*fdisk udebs. > > - the gnu-cfdisk udeb depends on ncurses, which is not acceptable > > In that case we could provide gnu-fdisk only. OK. > 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) My conclusion remains that we currently do not need/want either of the gnu-*disk udebs. Note that this policy is not something that I have invented. Joey has also always been quite strict about adding new udebs, or even new commands (such as ping) to D-I. Cheers, FJP Note: I appreciate all these creative technical solutions for debian-cd and accepting new udebs. Yes, improvements are undoubtedly possible, but I prefer to work based on the toolset that is actually available, not some imaginary features that nobody is likely to implement (assuming that they would be accepted by the relevant maintainers). 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.
Attachment:
pgpGj3YU2Nhg2.pgp
Description: PGP signature