Rationale behind modular repos disabled on Silverblue

Project Discussion
1

Currently, modular repositories are disabled by default in Fedora Silverblue {30,31}.

These repositories contain important software like sway and ripgrep to name a few.
Is there any reason on why they are disabled? Have in mind that there is no
clear way of managing repositories with rpm-ostree and users have to edit a file that is located, for some reason, in /etc/yum.repos.d/.

2 Likes
2

Did you try enabling it?

3

I have succesfully enabled it in /etc/yum.repos.d/fedora-modular.repo and /etc/yum.repos.d/fedora-updates-modular.repo by changing enabled=0 enabled=1 under [fedora-modular].
It works but i would also like to know if it is disabled for a good reason.

Edit: The modular repos can be enabled from Gnome Software’s “Software Repositories” menu now.

1 Like
4

Enabling them is a simple task, my questions is why this is the default, considering that it is different from the default in Workstation.

1 Like
5

I think it has to do with modular being available in containers anyway, so why enable it on RPM-OSTree? It will just dirty things up!

2 Likes
6

I use ripgrep, exa, fd and bat instead of their counterparts on a regular basis. Maybe I could use toolbox run to execute them from inside the toolbox tho.

7

What I use are bash aliases. In my ~/.bashrc I have:
alias htop=“toolbox run htop”

Then I can run just ‘htop’ as it was local app. The same for vim or midnight commander for example.

8

I did a small benchmark for fd and the toolbox run version was around 10 times slower, this negates one of the mayor benefits of fd, I suppose the history is similar forrg.

1 Like
9

That’s discouraging. I’m using an Ansible role for the cli tools I use. It downloads static builds of rg, pandoc, exa, fff and a few others, and places symlinks in ~/.local/bin. This works quite well, but I have to sign up for notifications on new releases on github and add version numbers manually as vars in the playbook. I’d prefer if I didn’t have to do this, but running a command like rg needs to be fast. I have nvim run rg (through the ctrlsf plugin) on a big codebase frequently. It’s either the ansible role or layering.

10

If I am not wrong, here is the reason why modular repos are not yet enabled by default.

This is the GitHub issue tracking the server side component.

1 Like
11

I made this ansible job for getting ripgrep

- hosts: localhost
  tasks:

  - pip:
      name: ['github3.py', 'selinux']

  - name: Get latest release of ripgrep
    github_release:
      user: BurntSushi
      repo: ripgrep
      action: latest_release
    register: release
  - name: Download ripgrep
    unarchive:
      src: 'https://github.com/BurntSushi/ripgrep/releases/download/{{ release.tag }}/ripgrep-{{ release.tag }}-x86_64-unknown-linux-musl.tar.gz'
      dest: '/tmp'
      remote_src: yes
  - name: Install ripgrep
    command: mv /tmp/ripgrep-{{ release.tag }}-x86_64-unknown-linux-musl/rg ~/.local/bin/rg creates="~/.local/bin/rg" removes="/tmp/ripgrep-{{ release.tag }}-x86_64-unknown-linux-musl/rg"
  - name: Make ripgrep executable
    file: path=~/.local/bin/rg mode=0755
  - name: Cleanup ripgrep installer
    file: path=/tmp/ripgrep-{{ release.tag }}-x86_64-unknown-linux-musl state=absent

It automatically detects the lattest release. I just learned ansible if there is anything that could be improved pls tell.

1 Like
12

Oh! I didn’t know about the github_release module, that looks very handy. I will definitely steal part of your tasks. Thanks for sharing!

I see no real room for improvements, btw. Except style and formatting (I prefer line breaks and indentation instead of equal signs for the file tasks and creates/removes as args on separate lines, for instance), but that’s a matter of taste. Oh, and do you need the “removes” bit? What does it accomplish that creates doesn’t already take care of?

13

To be honest I don’t know, but I imagine that one could replace mv with cp, and ansible doesn’t have any way to know that a file is no longer there.

14

Looking at the task one more time… will it actually overwrite the executable with a new version? I don’t see how that happens exactly, maybe I don’t know what the github_release module really does. Also, it will download the release with unarchive every time it’s run, won’t it? I’ve been using a task where I’m downloading to a new versioned directory in ~/.local/src (but could be anywhere) and symlinking the executable to ~/.local/bin. This will of course get bloated with old versions over time, but there’s little room for errors, at least. I’m looking into creating a pruning task, but not sure how I would do that based on version numbers. Maybe a post-task stat and then delete based on not containing current tag, but it will need some work.

15

This job just download the latest release (even if it is already installed, that is room for improvement) and installs the binary in ~/.local/bin, deleting the archive and all residual files.

16

This should be documented somewhere, with a big warning sign about it being unsupported and possibly leading to weirdness.

17

while it is not completely supported, you can enable the modular repos and install package from them.