How does the-new-hotness handle a repo change?

Ask Fedora
1

In this Github issue a question is put forward, which can be summarized as:

I’m the maintainer of the neofetch package for Fedora. Is changing the upstream repo for an existing package a common method? I know it’s a fork of neofetch, but it continues under a different name, right? Wouldn’t it make more sense to start a new package called hyfetch with the new repo? Then we can just retire neofetch. I don’t have the time or interest to package hyfetch, so if someone else wants to package that one. There is also fastfetch.

In case the Fedora dev community thinks it’s a good idea to switch to a different upstream source, but keep the name of the original package name, then I’ll fix that and continue. But I personally think it’s messy. What if the original maintainer of neofetch starts developing again?

My solution would be to start a new package, and if neofetch is really unmaintained, the package can be retired. With maybe something in the spec file of hyfetch that it replaces neofetch?

1 Like
2

Any (strong) opinions about this issue? I keep getting automated Bugzilla tickets on my name because I suppose someone set up this release monitoring for my package. But I personally think it’s wrong. The forked project should be packaged and if neofetch is really unmaintained, it should be orphaned. And perhaps the new hyfetch package can be configured to provide the virtual neofetch package as well?

3

As long as the package has a maintainer (you) it will not get retired.

Just try to get rid of the maintainer job for this package. If no body takes over the package gets retired because of missing maintainer.

And yes fastfetch is much faster, and in my opinion it does the same.

4

True, that’s an option, to retire the package. But I’m a bit confused why the release monitoring is now tied to a forked project of neofetch. I will not release neofetch with code from another project. If neofetch for whatever reason gets back on track, then I have a version issue.

But I guess I can just ignore these automatic tickets that are raised by the release monitoring. I also find it strange that someone else messed with this. Because I didn’t change the release monitoring.

5

This case is a little tricky, because hyfetch is quite clearly a fork that builds on the neofetch sources, provide neofetch, and is intended to replace it:

This repo also serves as an updated version of the original neofetch since the upstream dylanaraps/neofetch doesn’t seem to be maintained anymore (as of Oct 27, 2023, the original repo hasn’t merged a pull request for almost 2 years).

Anyone can update things on release-monitoring.org—that’s a public resource. This means there can be multiple people modifying the information. For example, in Fedora, you may want to retire neofetch and have hyfetch etc. obsolete it, but other distros may keep the neofetch name but use the hyfetch sources.

In this case, since hyfetch does provide neofetch, the latter is also OK. I know there’s always the risk of an inactive project returning, but if neofetch hasn’t been active in a number of years now, it is safe enough to use a fork. If it does return, the fork can be merged back in etc. to continue the versioning (but no PRs have been merged into neofetch in a number of years either). Versioning can also be fixed downstream using Epochs and so on, so there are options.

fastfetch does not say it’s an updated neofetch, so that should be a different package:

Fastfetch is a neofetch-like tool for fetching system information and displaying them in a pretty way. It is written mainly in C, with performance and customizability in mind. Currently, Linux, Android, FreeBSD, MacOS and Windows 7+ are supported.

If you don’t want bugzilla tickets about new releases, you can just disable monitoring at Overview - rpms/neofetch - src.fedoraproject.org (see the left hand side bar).

Ultimately, the question of whether hyfetch is packaged separately to obsolete neofetch, or if you keep neofetch and just use the hyfetch sources, is up to you, the neofetch maintainer. If you’d rather a new package, that is a perfectly correct way to go :slight_smile:

2 Likes
6

Thanks for the detailed answer! I think I will switch the upstream source to this hyfetch fork. But first I’ll inspect the fork a bit better and see if there is a way to provide both hyfetch and neofetch with the same package. I believe this is possible, I’ve seen it before. But I’ll have to go through the RPM dev docs again.

Edit: I just had a look at the hyfetch project. It’s more than just a fork, they seem to be moving to a more Python based application. I’ll orphan neofetch in that case and someone else may package hyfetch and go through a new package review. I think I’ll orphan it sometime later this year. Just in case any activity sparks up for neofetch. If not, then I suppose Fedora 41 won’t have neofetch anymore.

In case someone wants to package hyfetch, here’s an example:

1 Like
7

I’ll orphan the package this week.

1 Like