Issue #521: Finding and installing Linux applications

I feel like we kind of lost a little bit of focus and the message intended.
I think we need something like this:

Abstract
There are many powerful application software for the Linux OS. One can find an equivalent for almost any application used on other systems on a variety of sources. We give here an overview and a guide to the installation.

Sources of Applications

  1. Fedora Repository
    Characteristic: Pure Open Source, QA by Fedora team, RPM format
  2. Fedora Flatpack
    Characteristic: TPD (don’t know)
  3. COPR
  4. Generic Flatpak
  5. Third Party RPM Repositories
    Characteristics: Adjusted to Fedora or generic RPM, not as strict OSS as Fedora.
    Well known
    (List of 3rd party repos)
  6. RPM downloads from project site
  7. Foreign Repositories, e.g. deb

Brief discussion pros and cons, possible recommendation, note on precautions. Reference to the workstation debate about third party repos and the solution agreed to.

Installation Procedures

  • Fedora RPM
    (Description)
  • Gnome Installer
    (Description, maybe Link to an Article “Using Gnome Installer”)
  • KDE Installer
    (Description, maybe Link to an Article “Using KDE Installer”)
  • Installing from source
    (Short description, Link to Article)
  • Command line installation
    (Short description)

It would be kind of combination of the old and the new version of the article.

What do you think about it?

1 Like

i shared a table of content / synopsis as comments in Pagure issue a month ago in December prior to taking on writing a draft.

https://pagure.io/fedora-docs/quick-docs/issue/521

What you suggests overlaps with various pages in the ‘Adding and managing software’ section. There are dedicated pages on repo, flatpaks, COPR, thirdparty repo. My suggestions in issue list were made after hours of testing and gap analysis.

To avoid duplication of efforts and contents, we need to address the previous comments left in the issue board. And after hours of reflection, I suggested ToC and how-to-guide rather than tutorial.

Could we wait for more comments and you can revert it to previous state.

Yes, I know. But we lack an article which provides an overview and some overall guidance. Maybe, we should make the section title “Adding and managing software” into an overview article with annotated links to the several details article.

Revert to previous state is not the solution. Maybe, we should turn the “Finding and installing …” article into 2 articles: “Managing applications with Gnome” and “Managing applications with KDE”.

big changes may be coming down the pipe on this! :slight_smile:

https://pagure.io/fesco/issue/2939

Usually, I will only take this route when neccessary. It is usually certain feature from a application only exist in some version, which the RPM is older.

What I need from the document is:

  1. How about avoid both RPM and source conflict with each other
  • I usually use RPM to install the older version then install by source, as it usually will take care of dependency issues for the source version
  1. What will be the implication for future updates like “dnf upgrade”
  2. Common issues that might arise when doing install by source version
  • selinux policy
  • firewall
  • that is, all the steps taken care by dnf, now needs to be done manually.

For this one, I want the document can highlight the difference of
$ sudo dnf install
$ dnf install
$ sudo dnf search
$ dnf search

Last time I checked, even after $dnf serach, then following by $sudo dnf install, dnf still need to download and precess all the meta data again. As those are separate between different users.

The first three sections (package management system, dnf package manager, Fedora repositories) serve as introduction, which don’'t tell readers ‘how to’. This is exact opposite to what you pointed out, to be fair. So many intro, not enough how to.

Upstream docs on GNOME Software and KDE Discover were exactly the same - abundance of intro and not enough hands-on material.

I see latest articles have the overview section briefly. I’m rather careful of use of links overall as it can look messy and theoretical article/CS101 (first day). Rationales of links as content reuse seem plausible. But in reality, links used in abundance mean the article is not self-contained.

I also noticed recent pattern of its use on header or on reference section.

Ok, we gotta meet somewhere in the middle. I’ll dwell on how to restructure the article and many procedures I have to tackle for successful PR.

Thanks for your heads-up.

I think there are separate pages such as;
Adding or removing software repositories in Fedora
Enabling the RPM Fusion repositories

We need to manage any changes in there.

Not a bad idea to include a section on common language specific installers. In particular, pip comes up regularly on ask.fp.o and a best prescribed guide for using venv or toolbox for installing this way would be very useful. I feel like I often end up typing out the same things about this over and over, so having a well written stub for it would be helpful. It’s not specific to python, as ruby also comes up, but the gist is the same - use rvm or a container, etc, so you don’t risk conflicting with dnf installed libraries.

Thanks for your suggestion. There are dedicated pages and Fedora developer portal on language specific installers.

@pboy @darknao Suggestions made here converge upon existing QuickDoc articles. Splitting #521 into small pieces isn’t the answer for scope creep because we will see more duplicated content. We also need to consolidate some of old articles into new pages.

As a side, we need content review across multiple teams to have consistent content and reduce duplicate knowledge across other team pages and the Developer Portal. It sounds overwhelming, but if we include one other team that converges on a new article we produce, that’ll do.

For example,

  • Desktop specific GUI installers (GNOME Software, KDE Discover): Workstation SIG
  • dnf: QA Team
  • Language specific installers or process: …

Could there be notes added on which should be the most secure sources to the least secure? For example, and feel free to disagree, I think the Fedora repos are the most secure, followed by Flathub. After that a user should have more caution about using repos from any other source. There could be a blurb about what to look out for when deciding if an app is trustworthy (do you trust the developer, community, reputation of the app, etc). After that would be other sources to look like the Copr repos and other third party repos. Yes, there are lots of ways to get what you need, but you can’t trust all places equally.

Could also be overkill for this page? :sweat_smile:

There are separate pages that are best suited to your suggestions to include such judgement call;

Adding or removing software repositories in Fedora

Enabling the RPM Fusion repositories

COPR

1 Like

I figure it’s still worth mentioning on a potential “how to install Linux applications” page, especially because there you can provide context for how trustworthy to consider each source in relation to others. It could also consist of just a little text box. But if that doesn’t happen it’s not the end of the world.

Relevant sections already have put provisos here. The term ‘secure’, ‘trustworthy’ , ‘blob??’ does not appear suited to ‘how-to’ guides. I’m also wary of many overused ‘call-out’ in the articles that get in the way of flow of reading. The Fedora documentation style guide also puts it;

Use Admonitions very sparingly

They strongly interrupt the reading flow and thus make it difficult to grasp a section of text or even the article as a whole in a meaningful way.

It’s a matter of displaying opinions and I have no means to agree with yours.

quote=“Sampson Fung, post:5, topic:46229, username:sampsonf”
Usually, I will only take this route when neccessary. It is usually certain feature from a application only exist in some version, which the RPM is older.
[/quote]

I picked it up and turned it into issues in Quicke doc repo:

#553 Possible Improvement of “Installing software from source on Fedora”

#554 Possible improvement of “Using the DNF software package manager”

1 Like

You are right, indeed. And at the same time posts here show that overview information is missing. For example, about the differences between the various software sources.

I am a little puzzled after reading all the posts in this thread. Obviously the section “Adding and managing software” needs a thorough revision. How can we proceed?

See the image below for more conversation.

Screenshot_20230201_204039

The six pages under the section “Adding and managing software” are loosely coupled, but incoherently progress page to page. This means we need to take into account those pages as ‘one intro chapter’ followed by repo types, but not in silo. I have noticed some duplication of content across the initial six pages.

I’m not saying that my latest commit was a better option. But it is rather ‘renovation’ that I hoped it to blend in. I admit I made a mistake to edit the source file directly as I was struggling with Pagure PR process. Now, it is solved following a shallow learning curve. I’ll keep to the best practice next time.

What bothers me is one super comprehensive update on #521 as recommended by community members here and @pboy would stick out of the entire section. To put it another way, it does not blend in but might look patched up if we push a comprehensive #521. That’s where my gut reaction kicked in to resist scope creep and pause.

We need to be aligned with the expectation.

Then we can reach a consensus on synopsis and break them down to pieces.

I think I need some more volunteers and co-authors who are interested in reorganizing this section and revise them in its entirety together. As these pages are closely related to Workstation/Spins/Labs, I think it will be effective to work cross-team.

If you are not sure about this, can we chat over the phone when you are free after FOSDEM? I’m new here, but sometimes struck by the wall of text in spite of best intention and appreciation of async communication. Best if I could go over to FrOssDEM, but I have other commitments this weekend.

In retrospect, we need a new page ‘Install on Dev environment’ section. Created issue ticket here.

https://pagure.io/fedora-docs/quick-docs/issue/563

1 Like

Hi all, I appreciate if anyone wants to have a look at my PR for rewritten text. Thanks.

https://pagure.io/fedora-docs/quick-docs/pull-request/566

1 Like

issue #521 resolved with image rendered and introduction on repository added.

Thanks to @pboy for your help with alternative ideas, revisions and image macro. Every time I run local preview led me think build script is awesome!

@hankuoffroad First of all, a big sorry for my overly late response here. I am so swamped that I can’t even keep up. Let’s agree on when to chat over the phone.