Hi all,
As one of the main maintainers of the Rust stack in Fedora, I propose that ytop and its non-shared Rust dependencies (as in, only ytop depends on them) are retired.
ytop has been officially deprecated and unmaintained by upstream for over a year: https://github.com/cjbassi/ytop/commit/5d1e2fd Even the upstream developer recommends to use other programs instead.
Due to the statically linked nature of Rust binaries, old ytop builds should continue to work, since it links to no shared libraries except libc, libm, and libgcc_s. But making sure the package also keeps *building* successfully is no longer worth the effort IMO, because it involves working around its increasingly outdated dependencies - just to keep unmaintained software available as an RPM package. So I intend to retire the following packages from rawhide / f36+ if there is no opposition to this plan within two weeks:
- rust-ytop - rust-platform-dirs (only depended on by ytop) - rust-psutil (only depended on by ytop) - rust-platforms ((only depended on by psutil)
Fabio
On Sun, Sep 26, 2021 at 9:15 AM Fabio Valentini decathorpe@gmail.com wrote:
Hi all,
As one of the main maintainers of the Rust stack in Fedora, I propose that ytop and its non-shared Rust dependencies (as in, only ytop depends on them) are retired.
ytop has been officially deprecated and unmaintained by upstream for over a year: https://github.com/cjbassi/ytop/commit/5d1e2fd Even the upstream developer recommends to use other programs instead.
Due to the statically linked nature of Rust binaries, old ytop builds should continue to work, since it links to no shared libraries except libc, libm, and libgcc_s. But making sure the package also keeps *building* successfully is no longer worth the effort IMO, because it involves working around its increasingly outdated dependencies - just to keep unmaintained software available as an RPM package. So I intend to retire the following packages from rawhide / f36+ if there is no opposition to this plan within two weeks:
- rust-ytop
- rust-platform-dirs (only depended on by ytop)
- rust-psutil (only depended on by ytop)
- rust-platforms ((only depended on by psutil)
Fine with me. +1
Can we also get rid of this in F35 too?
On Sun, Sep 26, 2021 at 3:17 PM Neal Gompa ngompa13@gmail.com wrote:
On Sun, Sep 26, 2021 at 9:15 AM Fabio Valentini decathorpe@gmail.com wrote:
Hi all,
As one of the main maintainers of the Rust stack in Fedora, I propose that ytop and its non-shared Rust dependencies (as in, only ytop depends on them) are retired.
ytop has been officially deprecated and unmaintained by upstream for over a year: https://github.com/cjbassi/ytop/commit/5d1e2fd Even the upstream developer recommends to use other programs instead.
Due to the statically linked nature of Rust binaries, old ytop builds should continue to work, since it links to no shared libraries except libc, libm, and libgcc_s. But making sure the package also keeps *building* successfully is no longer worth the effort IMO, because it involves working around its increasingly outdated dependencies - just to keep unmaintained software available as an RPM package. So I intend to retire the following packages from rawhide / f36+ if there is no opposition to this plan within two weeks:
- rust-ytop
- rust-platform-dirs (only depended on by ytop)
- rust-psutil (only depended on by ytop)
- rust-platforms ((only depended on by psutil)
Fine with me. +1
Can we also get rid of this in F35 too?
I mean, sure, I don't see a reason not to do this for F35 as well. But until which point is it possible to retire packages from F35? Start of final freeze?
On Sun, Sep 26, 2021 at 9:20 AM Fabio Valentini decathorpe@gmail.com wrote:
On Sun, Sep 26, 2021 at 3:17 PM Neal Gompa ngompa13@gmail.com wrote:
On Sun, Sep 26, 2021 at 9:15 AM Fabio Valentini decathorpe@gmail.com wrote:
Hi all,
As one of the main maintainers of the Rust stack in Fedora, I propose that ytop and its non-shared Rust dependencies (as in, only ytop depends on them) are retired.
ytop has been officially deprecated and unmaintained by upstream for over a year: https://github.com/cjbassi/ytop/commit/5d1e2fd Even the upstream developer recommends to use other programs instead.
Due to the statically linked nature of Rust binaries, old ytop builds should continue to work, since it links to no shared libraries except libc, libm, and libgcc_s. But making sure the package also keeps *building* successfully is no longer worth the effort IMO, because it involves working around its increasingly outdated dependencies - just to keep unmaintained software available as an RPM package. So I intend to retire the following packages from rawhide / f36+ if there is no opposition to this plan within two weeks:
- rust-ytop
- rust-platform-dirs (only depended on by ytop)
- rust-psutil (only depended on by ytop)
- rust-platforms ((only depended on by psutil)
Fine with me. +1
Can we also get rid of this in F35 too?
I mean, sure, I don't see a reason not to do this for F35 as well. But until which point is it possible to retire packages from F35? Start of final freeze?
You can do it at any point before the final freeze, I believe.
On 26. 09. 21 15:20, Fabio Valentini wrote:
But until which point is it possible to retire packages from F35? Start of final freeze?
I recommend doing it a couple days before the freeze, as it happens asynchronously some time after the git push and sometimes it does not happen.
On Sun, Sep 26, 2021 at 8:13 PM Miro Hrončok mhroncok@redhat.com wrote:
On 26. 09. 21 15:20, Fabio Valentini wrote:
But until which point is it possible to retire packages from F35? Start of final freeze?
I recommend doing it a couple days before the freeze, as it happens asynchronously some time after the git push and sometimes it does not happen.
Good point. IIRC, retired packages get blocked by koji at the end of a successful compose. So, since the F35 beta freeze starts on Oct. 05, that means the packages would need to be retired on Oct. 03 at the very latest. If there's no objections, I'll retire the packages for f35+ on Oct. 01, just to be safe.
Fabio