Linux multi-boot release criterion discussion, redux

[Kamil Paral]

> > ===
> > 
> > When installing to a system containing an existing installation of
> > either the same Fedora release or either of the two previous releases,
> > the installer must configure the new installation's bootloader such that
> > it can successfully boot the existing installation.
> > 
> > [Footnote] Typical configurations only: This criterion applies only to
> > installations (both existing and new) using default or very common
> > storage and bootloader configurations.
> > 
> > [Footnote] Platforms: This criterion applies to all supported
> > configurations described in
> > [[Fedora_21_Alpha_Release_Criteria#Release-blocking_images_must_boot|the
> > Alpha criteria]], but does not apply to mixed configurations, e.g. it
> > does not require that a UEFI native installation of one Fedora release
> > be able to configure its bootloader to boot a BIOS native installation
> > of another Fedora release.
> > 
> > ===
> > 
> > How does that look? I think we had at least a consensus that this much
> > was reasonable, and we have two bugs currently that would likely violate
> > the proposed criterion:
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=825236
> > https://bugzilla.redhat.com/show_bug.cgi?id=964828
> > 
> > I think it's reasonable to consider these blockers for F21, but we
> > should justify it ASAP to give the devs sufficient time to fix them.
> 
> I'm all for getting those bugs fixed, but making it an official
> criterion is basically adding an anaconda requirement and a new feature
> to the distro.  Doing that at the end of a cycle isn't really okay, and
> doing it without any mention on anaconda-devel-list or fedora-devel-list
> for discussion isn't really that great, either.

I'm in favor of adding such a criterion. And I agree it's too late for F21, so it should target F22. Of course, that doesn't preclude anaconda devs from best-effort to fix those bugs, if they have spare time.

> 
> Also this criterion as written is going to bring in more than just those
> two bugs - for example, right now we don't /really/ support two UEFI
> Fedora installations on a single disk without the user making some
> fairly strange choices, and when you do that, some things such as
> fallback (which admittedly aren't in the criteria AFAIK) don't work.
> 
> Fixing that would be a fairly substantial RFE, so either we need to have
> language in any potential new criterion to accept the current conditions
> (e.g. by requiring two separate disks to put an ESP on each), or we need
> to plan on adding support for that before we apply any new criteria.

I was about to mention the same, Fedora UEFI dual-boot requires a lot of manual tweaking at the moment, and I guess it's not something that can be changed and properly tested in a few weeks.