search

cjbassi / ytop

A TUI system monitor written in Rust
MIT License
2.16k stars 84 forks source link

README: Add Fedora instructions #81

Closed ignatenkobrain closed 4 years ago

ignatenkobrain commented 4 years ago

Note that they are still in testing repos, so probably we should merge this in 2 days.

cjbassi commented 4 years ago

So I actually just updated the readme and I'm now using repology to show the available packages, which makes things easier, so I'm not sure if we need to add this to the readme. But thanks anyway!

ignatenkobrain commented 4 years ago

@cjbassi in that case, you probably should remove:

Updates in official Fedora/EPEL repositories may lag at this moment. As an alternative you can install from COPR:

sudo dnf copr enable atim/ytop -y
sudo dnf install ytop
cjbassi commented 4 years ago

I'm really not familiar with fedora packaging, but here's the discussion and pull request for that snippet: https://github.com/cjbassi/ytop/pull/50

Are you saying that we don't need copr anymore because you are packaging it for fedora now?

Also, ping @tim77

ignatenkobrain commented 4 years ago

Basically yes. Though we don't do EPEL, so I guess you can keep that section for CentOS only.

The main difference is that in copr, it doesn't get signed by fedora key, doesn't get distributed via standard repos and built with internet enabled which means nobody can reproduce builds. On top of that, those builds are most of the time not fully optimized.

ignatenkobrain commented 4 years ago

Essentially installing such RPMs from copr is no different than running cargo install ytop

tim77 commented 4 years ago

I'm really not familiar with fedora packaging, but here's the discussion and pull request for that snippet: #50

COPR is part of official Fedora infrastructure. Many COPR maintainers are Fedora maintainers and this could easily checked by clicking on their profile info on COPR page.

Are you saying that we don't need copr anymore because you are packaging it for fedora now?

Also, ping @tim77

It's entirely on you. But point in #50 will be always actual since updates may lag and sometimes they lags hard since you need update or package new crates which new version requires or messing with compat packages, sometimes may not work properly at all (updated three month later this is super fast for sure). Just one fact that there is still no new Rust maintainers joined for all this years says a lot. No one in sane mind don't wont to spend half of their life, updating crates and doing monkey job basically which MUST do a bot. While some people are working on solving real problems and dependency hell in particular, one other person inventing dependency hell in Fedora. BTW there literally only one person can build and push updates in Fedora for non-Rawhide branch. Hope you understand the point.

On top of that, those builds are most of the time not fully optimized.

Show us the proof which proves that ytop in this COPR is less optimized than version in standard repos which was finally packaged 2 month later, or stop spreading nonsense and FUD.

Essentially installing such RPMs from copr is no different than running cargo install ytop

Oh yeah, of course. Then all other distros should stop packaging this way because you saying. Try better next time.

ignatenkobrain commented 4 years ago

Show us the proof which proves that ytop in this COPR is less optimized than version in standard repos which was finally packaged 2 month later, or stop spreading nonsense and FUD.

The COPR version lacks at least few basic things:

What I want to avoid is having bugreports in Fedora packages saying "hey, new version is not working" and me replying there "sorry, you installed package from some random COPR and I can't help you".

By the way, I have wrote an email to the Fedora devel ML which is supposed to answer some of your points: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/UE4FU27OAHXQ2EOV5OFSXGHELUWZYSJM/

tim77 commented 4 years ago 
* 0.5.1 was available in Fedora at 2020-03-19 (https://koji.fedoraproject.org/koji/packageinfo?packageID=30990). not for all releases, because there was simply no point in doing that for development version of ytop.

Really? Because you saying no point mean everyone shouldn't use app? And all other distros packaged it because "there was simply no point"? It's the same development version as current 0.6. If you can't package it for non-Rawhide Fedora release it's your problem (as always), not ytop.

* 0.6.1 was available in Fedora at 2020-05-11 (one day after release, https://koji.fedoraproject.org/koji/packageinfo?packageID=31254)

* 0.6.2 was available in Fedora at 2020-05-17 (less than 8 hours after release, https://koji.fedoraproject.org/koji/packageinfo?packageID=31254)

It's good to know that your never sleeps and updating manually all crates in day an night, but in COPR ytop was built in the same day when released for all Fedora branches and RHEL/CentOS.

Also why you selectively and blatantly showing apps which you updated? Why you not show your staled and broken packaged for 3 month, like Zola?

The COPR version lacks at least few basic things:

* Bunch of optimization options (like `-Copt-level=3` and `-Ccodegen-units=1`)

It's built with release profile which compiles with -C opt-level=3 by default. You should be ashamed for such plain and dumb lying.

As for -Ccodegen-units=1 i don't mind enable it for popular apps sacrificing to compile time. Enabled for ytop. Now COPR build is more optimized than build in standard Fedora repos. Binary size ver 0.6.2:

* Debuginfo entirely (if the user has any problem, he won't be able to provide any useful debug information)

This is one of the most hilarious point. ABRT and automatic reporting doesn't work for Rust packages as you said earlier. How many such reports with debug info was reported for all this years, zero or slightly less? You right, user has problems and this problem is you. Users will never have many useful rust apps in Fedora, any GNOME apps in particular. There is still any gnome app not packaged which using gtk-rs and never will until we will deal with you. One of the reason is why gnome devs are running away from Fedora to Flatpak and Arch. Thanks for ruining Rust in Fedora.

In any case enabling debug info for optimized builds in copr not hard. If there was need for this.

What I want to avoid is having bug reports in Fedora packages saying "hey, new version is not working" and me replying there "sorry, you installed package from some random COPR and I can't help you".

What you want you already achieve, is bugs introduced by Fedora itself and exactly "hey, new version is not working" (see Zola bug RHBZ#1833304).

And hey, this is not "some random COPR", this COPR which mentioned in Fedora Magazine. Stop being ignorant already.

By the way, I have wrote an email to the Fedora devel ML which is supposed to answer some of your points: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/UE4FU27OAHXQ2EOV5OFSXGHELUWZYSJM/

By the way we tired of yours fairy tales and no one even getting hit on your this bait. And you forgot to tell others people how you have stale and broken for 3 month app in non-Rawhide branch. Also what the point of posting the same posts about how awesome Rust is packaged in Fedora devel mail list and discuss this with the same 2.5 people who the only one agree with this? Try open you eyes already and try admit when you wrong. Rust have big community and no one except you and one more person don't want messing with all your mess which you invented in Fedora with Rust. For all this years. This mean that there will no contributors in Fedora. Thank you for all your work.

cjbassi commented 4 years ago

I just updated the readme and removed the wording about ytop potentially lagging in the official fedora repos, which hopefully clears up this issue. Feel free to let me know if anything else should be changed.