This is not a formal proposal, this is for discussion and identifying
liabilities. This email has an x86 GRUB bias only because that's the
bootloader regime I'm most familiar with. I think it should apply to
other archs as well, i.e. their bootloaders shouldn't be permitted to
Short version: Fedora should take responsibility for the bootloader
being up to date, by updating it during major version upgrades. This
is already the case on UEFI with conventional installations. I'd like
to make sure it always happens on major version upgrades for BIOS
installations. What's the problem? This would step on any custom
bootloader configuration a user has for multiboot. There is no
reasonable mechanism on BIOS systems to determine if the bootloader is
a Fedora bootloader, and somehow only update a Fedora bootloader and
not touch any other bootloader.
Fedora should be responsible for keeping the bootloader it installs in
~80% of the use cases up-to-date; and ignore the fallout from the ~20%
who have a custom setup that would be stepped on by a forced
bootloader update. The former is a feature and security risk, by
allowing the bootloader to go stale over time. The latter is an
bootloader - this is the pre-boot bootloader binaries; on BIOS it's
embedded in the MBR, and the MBR gap or BIOS Boot partition, and
modules found in /boot/grub2 on Fedora. On UEFI, this is the
/EFI/fedora/shimx64.efi and /EFI/fedora/grubx64.efi which in the
typical installation are built and signed by the Fedora build system.
Other bootloaders have different names but generally follow a similar
convention, the point here is to distinguish between the "bootloader"
which runs in the pre-boot environment, and the installed package
containing user space tools that are used to install (or contain) the
Fedora bootloader - this is a bootloader that is derived from Fedora
packages and effort; as contrasted to merely upstream GRUB, or
Ubuntu's GRUB, etc. as these derivatives can actually be substantially
different from each other.
Both gnome-software (pk-offline-update), and dnf system-upgrade, on
BIOS firmware x86 computers, do not update the bootloader. That is, we
do not run 'grub2-install' either before starting an upgrade, or as a
post install operation following an upgrade. Therefore the bootloader
will become stale if the user does not manually run 'grub2-install'
On conventional Fedora installations on UEFI computers, the bootloader
is included in the shim and grub2 packages as a file, and is therefore
updated. This happens sporadically within a Fedora release, not only
at major upgrade time. This updating of the bootloader files doesn't
happen on Silverblue on UEFI, so it ends up being subject to the same
problem under discussion.
In the most recent release, Fedora 30, we saw quite a lot of people
run into a problem we knew about before release, directly related to
the bootloader becoming stale. And it only affected BIOS systems (and
Silverblue on both firmware types).
In the bug, you can find some dups as well but also quite a bit of
user aggravation. I'd like to avoid this going forward.
Windows and macOS never involved users in this stuff. They always
asserted complete and total domain over the bootloader, there wasn't
even an option to avoid updating it. And I think Fedora needs to do
the same. Just update it. That benefits most users. It's the
responsible thing to do. And those who need custom setups, can still
do that. It would only get stepped on at major upgrade time. And it's
decently likely we can warn them in advance.
There are some gotchas I'm already thinking of: MBR gap is too small,
there are multiple drives and it's ambiguous which one should get the
bootloader, and so on. I think it's sane to have a test for reasonable
certainty we can and should update the bootloader, and warn and not
update it in the cases that fail that test.
Science, like Free/Open Source software should be open for all to use,
modify, explore, learn, and share. This is especially important to
ensure that the results from scientific work are not merely limited to
"academia", but are easily understandable by people in other walks of
life also. Further, science should not be limited to "academia".
Everyone should have access to the data, the tools, the knowledge.
With this in mind, we started the NeuroFedora SIG that focusses on
Neuroscience (mostly because my field is neuroscience):
However, there's a lot of work that can be done to enable all scientific
fields, not just neuroscience. So, we're hoping to meet at Flock to
discuss how we can better use Fedora's resources to enable Free Science.
We've applied for a hackathon at the minute. If we're unable to get a
slot, we'll meet informally over beers ;)
The session is open to everyone, of course, and we'd love for more
people to join in. There's a lot of science to be learned, and there's a
lot of FOSS to be learned too, so we need people from both sides!
Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London
Hi R-interested packagers and others,
Recently, I've been looking at how RPM can automatically determine
Provides and Requires . I have since implemented this for R using
an R script  and some file attributes . Following other
languages' Provides, I have namespaced them as R(packageName). It then
adds corresponding Requires, Suggests, and Enhances.
Additionally, R package versions commonly contain dashes. In order to
work in RPM, these are replaced with dots. For the automated
Provides/Requires, I have used the *real* versions instead.
So now the question is how to apply this. I expect there are social
concerns, i.e., discussing with the R maintainer, making a
Self-contained Change, etc. But for this email, I am mostly concerned
with the technical aspects:
1. Is R-devel the right place to put the script and RPM attribute file
(all R packages would normally depend on this)?
2. Does this namespacing make sense?
3. Are dashes in *namespaced* versions going to be a problem?
4. Python had a flag to enable the automatic generator; do we need
this for R, and how was it implemented?
5. I expect this would need a rebuild of all packages to get the
dependencies right (because the regular rebuild is unordered); would
this need a side tag? Or would leaving it for the normal mass rebuild
just be fine?
6. R only has two levels of dependencies (hard-require or suggested,
but not installed by default). Thus both build- and runtime-optional
packages are in Suggests; do we care about the extra Suggests?
With Python 2 slated to be removed, I'm going to retire these packages
where upstream has either stopped development (Obnam's dependencies) or
is moving too slow to get a stable Python 3-based release out
(gnumed-server). Also, I've been helping out with gnumed (the client)
but never officially maintained it, and that package is already retired
in Rawhide due to being orphaned - so there's no reason to keep the
List of packages as follows, I'll hold off until Friday before retiring
them if someone wants to take over these packages and get them built. If
you take over gnumed-server you should take over gnumed and unretire it too.
Michel Alexandre Salim
GPG key: 96A7 A6ED FB4D 2113 4056 3257 CAF9 AD10 ACB1 BEF2