Re: Dropping old fdisk utilities
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
>
>
Reply to: