On Aug 29, 2014, at 2:55 AM, Adam Williamson <adamwill(a)fedoraproject.org> wrote:
>
> OS X
> ====
>
> I propose the following final release criterion:
>
> "The installer must be able to install into free space alongside an
> existing clean OS X installation and install a bootloader which can boot
> into both OS X and Fedora, OR the installer must prominently warn the
> user that he may be unable to boot OS X after installation, allowing the
> user to cancel installation and reboot to OS X."
>
> I think that requirement should be easy to meet, so I won't include
> links to the OS X bugs.
I don't have any particular argument with it, though I'm not sure if
it's entirely release criterion material. It'd be good to know what the
anaconda devs think.
I agree that immediate post install UX is anaconda domain, but neither the cause nor
solution for this problem is up to anaconda/blivet. I think the simplest solution is
delete/comment out lines 44-106 in /etc/grub.d/30_os-prober so that OS X entries
aren't created.
I don't believe it's feasible that broadly worded, no. There are a *lot*
of Linux distributions, and we certainly don't auto-detect even a
default installation of all of them, never mind all the crazy layouts
and bootloader configurations people might be able to come up with.
Note that we're heavily dependent on upstream code, here - we basically
farm the bootloader detection of other OSes out to grub2, which is what
other distros do as well. We probably all act fairly similarly here,
these days. /etc/grub.d/30_os-prober is what does most of the magic.
This is why I'd draw the line on owning our code. The two cited bugs are congruent
with this.
A more feasible criterion, for me, would be something like
'successful
dual boot with default single-disk install of other Fedora versions and
other "major" distributions', however we choose to define major exactly.
That may even be too broad. Keeping it narrow to "we're responsible for what our
code does different than upstream" has two benefits: we're hopefully not biting
off more than we can chew, and it leaves room for distros to agree on a (variant of )
BootloaderSpec. If there isn't the collective will to fix design flaws with GRUB2, I
don't see how it can be effective to achieve this on the back end with one
distro's release criteria.
Chris Murphy