----- 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 <dledf...@redhat.com>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
