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”.
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:
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
What will be the implication for future updates like “dnf upgrade”
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.
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
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.
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.
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?
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.
@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.
No problem. Take it easy. Don’t be sorry. Time lapsed and all sorted now auto-magically
The only thing I regret is I didn’t have two way merge review with experienced writers. I hope you understand. I just wanted to write up and to get four-eye review. Let’s chat on weekly Docs meeting.
