----- Original Message -----
> It's a bad design because it asserts something (grub versions are
> compatible with each other) that isn't true (they're not).
I've stated this once already, but since you glossed over it. It does not assert that grub versions are compatible, it asserts that the stage1 boot loader and the console utility are able to work with paired stage1.5 and stage2 loaders. Code inspection of the stage1 loader showed this compatibility assumption to be correct, and experience has shown the grub utility compatibility to be correct.
This is unlikely to change. As Peter has said, grub is dead, there is no upstream, other distros including Fedora are leaving it behind, so it is more or less a static target at this point in time, and we already have the experience based evidence that your fears are not founded in reality. Could there be incompatibilities? Yes. Are there? None found yet, and based upon code inspection, analysis of the code in question, the fact that upstream has been dead for years which tends to cause maintainers in distros to do the absolute bare minimum to keep their distros booting and discourages wild code changes that might destabilize things and introduce exactly the sort of incompatibilities you are afraid of, it is a reasonable engineering decision to decide to go with the existing code as it is and fix up any future incompatibilities that might arise, if they ever even do.
As such, it's *not* a bad design, it's an expedient design. It benefits from a certain amount of serendipity. It would be much riskier if grub were in active development. But it's not, we got lucky, it works as it is, so go with it. There's absolutely no reason not to, especially if Richard is willing to do as I suggested and just throw a current grub utility into libguestfs and be done with it.
> I don't
> have
> any idea how to solve this given the constraints that are being
> imposed,
> but this approach certainly isn't a solution.
It's a perfectly workable solution. You just don't like it on the basis of your own ingrained FUD against the idea that isn't even based on realistic future development of this dead end package.
--
Doug Ledford <dledford@xxxxxxxxxx>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
