On Fri, 22 Sep 2017, John Paul Adrian Glaubitz wrote: > On 09/22/2017 04:13 AM, Finn Thain wrote: > >> mac-fdisk in particular is no longer needed but it can cause trouble > >> with debian-installer when the udebs are outdated or broken. > >> > > > > If the package gets broken and if no-one will maintain it, then I > > won't object to its removal. Otherwise, why not cross that bridge when > > we come to it? I'm willing to fix more mac-fdisk bugs if need be. What > > is needed to keep up with changes in APT? > > The main problem is that mac-fdisk is not a package that is built on any > of Debian's release architectures. This normally means you cannot upload > a package through the regular FTP mechanism as the Debian Archive Kit > (DAK) will kick any package source which does not produce binary > packages on release architectures. >
That problem would affect bootloaders and other platform-specific packages for unofficial ports, right? > It still works at the moment because powerpc still happens to be built > on the official buildds and its packages are being stored on the main > FTP servers and not Debian Ports. So, technically, powerpc is still a > release architecture, it's just no longer part of Debian testing. > > However, we don't know how long this status will continue to remain in > the future and the moment powerpc is removed from the official > infrastructure, you will no longer be able to upload new versions of the > mac-fdisk source package as DAK will kick the package shortly after no > binary packages are built on the release architecture buildds. > Thanks for the explanation. > >> While amiga-fdisk is not used in debian-installer, we actually don't > >> need it either. parted works just fine for partitioning Amiga hard > >> disks. > >> > >> So, I would be in favor of removing both amiga-fdisk and mac-fdisk. > >> > >> Opinions? > >> > > > > I can say that one advantage of mac-fdisk over the other tools is that > > it works the same as pdisk on Mac OS X. So the risk of catastrophic > > operator error is reduced. Though it appears that the mac-fdisk code > > hasn't tracked Apple's pdisk code. Is there a licensing issue? > > I think parted has a much larger group of users, more documentation and > has received more testing. With gparted, it also has a very clean and > sensible UI, so I think people should be encouraged to use the modern > tools and also encouraged to report bugs and help developers improve the > code. > > Laurent Vivier recently fixed some issues in the Mac partition table > code in parted and I think he will be happy to do that in the > foreseeable future. > Sounds good. > > There is a risk that some quirks in the APM format, Mac OS, or Apple > > boot ROMs are not handled by other tools. I don't know. And I don't > > know that parted developers intend to match pdisk functionality in > > general. Given those uncertainties, I can't offer an informed opinion. > > Well, yes, but all those things are issues that can be resolved, if > necessary. > > Sticking to old and unmaintained software is never a good idea. It > causes additional overhead and is a possible source of bugs. For > example, mac-fdisk just recently broke debian-installer on m68k and I > had to fix it manually in order to get the installer working. > You and I, both. > The problem was that mac-fdisk still ships udebs for debian-installer > although these are no longer used as debian-installer always uses parted > for partitioning hard disks during installation these days. Yet, any > udebs available for a given architecture are pulled in during > installation and can therefore cause issues. > > So, mac-fdisk broke debian-installer even though it's not even needed by > d-i anymore. And that is one of the typical effects you see with > software that has been unmaintained for a long time. > I agree that d-i is more important than mac-fdisk, but AFAICS we aren't yet in a position where we have to choose between them. -- > Adrian > >
