releng/tickets

Fork 2

Retired packages are not properly marked in Pagure #11994

New issue

Open

opened 2024-03-04 09:44:00 +00:00 by vondruch · 8 comments

vondruch commented

2024-03-04 09:44:00 +00:00

Member

When package is retired, it should be marked as retired/unmaintained in Pagure. E.g. this is recent example of successfuly retired package:

https://src.fedoraproject.org/rpms/rubygem-rails-deprecated_sanitizer

However, libxslxwriter which was retired by proven packager is not marked as such.

Another example of such package can be this:

https://src.fedoraproject.org/rpms/pcmciautils

When package is retired, it should be marked as retired/unmaintained in Pagure. E.g. this is recent example of successfuly retired package: https://src.fedoraproject.org/rpms/rubygem-rails-deprecated_sanitizer However, libxslxwriter which was [retired by proven packager](https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/X6ADYQA27WRLDQYAL3MHMGCHN3NQY47S/) is not marked as such. Another example of such package can be this: https://src.fedoraproject.org/rpms/pcmciautils

churchyard commented

2024-03-04 11:02:16 +00:00

Member

Where exactly do I see a package in src.fp.o is retired?

rubygem-rails-deprecated_sanitizer is orphaned and retired on rawhide

libxslxwriter is not orphaned, only retired on rawhide

Where **exactly** do I see a package in src.fp.o is retired? rubygem-rails-deprecated_sanitizer is **orphaned** and retired on rawhide libxslxwriter is **not orphaned**, only retired on rawhide

churchyard commented

2024-03-04 11:04:57 +00:00

Member

Oh, I found a Retired button on the left where orphaned-only packages have the Take button.

Packages that are retired but not orphaned don't have it. I guess It makes sense to add it there.

Oh, I found a **Retired** button on the left where orphaned-only packages have the **Take** button. Packages that are retired but not orphaned don't have it. I guess It makes sense to add it there.

vondruch commented

2024-03-04 11:30:04 +00:00

Author

Member

TBH, I don't find the status "retired but not orphaned" very useful. Especially in the libxslxwriter case.

churchyard commented

2024-03-04 14:00:35 +00:00

Member

"retired but not orphaned" generally makes sense. e.g. I still maintain this on f39: https://src.fedoraproject.org/rpms/python-cython0.29

Once all branches are retired, packages get orphaned automatically. Technically, libxslxwriter is still "maintained" on f39 and f40 (the fact that this package was never actually maintained makes it a bad example).

"retired but not orphaned" generally makes sense. e.g. I still maintain this on f39: https://src.fedoraproject.org/rpms/python-cython0.29 Once all branches are retired, packages get orphaned automatically. Technically, libxslxwriter is still "maintained" on f39 and f40 (the fact that this package was never *actually* maintained makes it a bad example).

vondruch commented

2024-03-04 14:50:47 +00:00

Author

Member

Technically, e.g. pcmciautils is unmaintained for ages (and @harald should have been called unresponsive maintainer instead of forcibly retiring his packages).

Technically also rubygem-rails-deprecated_sanitizer should be maintained in F38 / F39. And also with a help of proven packager, it is still possible.

IMHO, there should be no difference between packages retired by somebody and by "orphaned" packages process.

Technically, e.g. pcmciautils is unmaintained for ages (and @harald should have been called unresponsive maintainer instead of forcibly retiring his packages). Technically also rubygem-rails-deprecated_sanitizer should be maintained in F38 / F39. And also with a help of proven packager, it is still possible. IMHO, there should be no difference between packages retired by somebody and by "orphaned" packages process.

music commented

2024-03-04 17:06:53 +00:00

Member

One example is libmetalink, which I’m planning to retire in F40 and F41 after the Beta Freeze lifts. It has been obsolete and unsupported upstream for over ten years, but it’s also a dependency for wget. With the retirement of wget as part of Wget2asWget, I can finally retire libmetalink – but that doesn’t mean I am not willing to take care of the existing branches. I suspect the attitude of the wget maintainers toward the now-retired wget package is similar.

It is reasonably common for me to retire packages (because of renaming, upstream reorganization, packages with long-dead upstreams finally becoming leaves, and so on), while still fully supporting stable branches. Usually no active maintenance is required, but in these cases I still want to be assigned and act on any bug reports for stable releases, and perhaps even provide security/bugfix updates if applicable. One example is `libmetalink`, which I’m planning to retire in F40 and F41 after the Beta Freeze lifts. It has been obsolete and unsupported upstream for over ten years, but it’s also a dependency for `wget`. With the retirement of `wget` as part of [Wget2asWget](https://fedoraproject.org/wiki/Changes/Wget2asWget), I can finally retire `libmetalink` – but that doesn’t mean I am not willing to take care of the existing branches. I suspect the attitude of the `wget` maintainers toward the now-retired `wget` package is similar.

phsmoura commented

2024-03-04 19:13:26 +00:00

Metadata Update from @phsmoura:

Issue tagged with: investigation, low-gain, low-trouble, ops

**Metadata Update from @phsmoura**: - Issue tagged with: investigation, low-gain, low-trouble, ops

jnsamyak commented

2025-09-30 12:03:00 +00:00

Owner

Hey folks, I went up to the package - and it is rightfully retired. Do we want to treat this ticket as an enhancement request on how to put reasons for retirement, or do you think we can close this?

CC: @music @vondruch @churchyard

Hey folks, I went up to the package - and it is rightfully retired. Do we want to treat this ticket as an enhancement request on how to put reasons for retirement, or do you think we can close this? CC: @music @vondruch @churchyard