Re: Proposing new dual booting release criteria

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Aug 29, 2014, at 2:55 AM, Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> 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

-- 
test mailing list
test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test





[Index of Archives]     [Fedora Desktop]     [Fedora SELinux]     [Photo Sharing]     [Yosemite Forum]     [KDE Users]

  Powered by Linux