Bug 2054662 - DNF should display a module end-of-life
Summary: DNF should display a module end-of-life
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf
Version: 38
Hardware: Unspecified
OS: Unspecified
low
unspecified
Target Milestone: ---
Assignee: rpm-software-management
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-02-15 12:52 UTC by Petr Pisar
Modified: 2023-08-23 15:14 UTC (History)
12 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2023-08-23 15:14:49 UTC
Type: Enhancement
Embargoed:


Attachments (Terms of Use)

Description Petr Pisar 2022-02-15 12:52:09 UTC
When testing modular obsoletes (implemented in bug #1863049), I was surprised that DNF does not exhibit a date of a module end-of-life.

According to the Fedora Change page <https://fedoraproject.org/wiki/Changes/Module_Obsoletes_and_EOL#Proposed_DNF_behavior>, obsolete streams are not by default replaced and it's up to the user to perform the replacement.

However, without displaying a date of the end of life of a stream, the user has no clue that the stream is obsolete or that it will reach its end of life soon.

I propose enhancing "dnf module list" output with the EOL date like this:

# dnf module list perl
[...]
Fedora Modular 35 - x86_64 - Updates
Name   Stream     Profiles                       EOL         Summary                                  
perl   5.30 [e]   common, default [d], minimal   2021-06-01  Practical Extraction and Report Language 
perl   5.32       common [d], minimal                        Practical Extraction and Report Language 

Fedora 35 already delivers EOL date for perl:5.30 as "2021-06-01T00:00Z". I think converting the time stamp to a local time zone and trimming/rounding it up to a day precision (e.g. "2021-06-02" in UTC+01 zone) would be great.

In Fedora, each stream has known EOL when the stream is created. Hence technically it would be possible to push these EOLs for all streams into a repository and the EOL column would be populated for all streams. It would mostly show a future data so that users can do an informed decision on which stream to choose and when to migrate to a different one.

If we had EOL at each stream, to make clear that some enabled modules are already expired, we would need some kind of highlighting. E.g.:

Name   Stream     Profiles                       EOL         Summary                                  
perl   5.30 [e]   common, default [d], minimal   !2021-06-01 Practical Extraction and Report Language 
perl   5.32       common [d], minimal            2022-06-01  Practical Extraction and Report Language 

Or instead of a new EOL column we can show a new flag with a meaning "this stream has already reached or will reach EOL in few days" (when the few days can be a configurable period) and let user use "dnf module info" to find out the exact EOL date:

Name   Stream     Profiles                       Summary                                  
perl   5.30 [!e]  common, default [d], minimal   Practical Extraction and Report Language 
perl   5.32       common [d], minimal            Practical Extraction and Report Language 

Or we can concise [!e] into [E].

Also it would be great if "dnf module info" reported the EOL time and an obsoleted-by (the new) stream values.

Comment 1 Honza Horak 2022-02-25 08:31:45 UTC
I like this proposal. I also prefer to include EOL date, over the concise [!e] or [E], which could be hard to understand without reading exact meaning ahead.

Comment 2 Petr Pisar 2022-04-01 13:36:29 UTC
When implementing this change, please bear in mind that modular obsoletes can apply, besides to a stream, also to a specific context of the stream.

Example: Having perl-DBI:S::C1 built for perl:5.30 and perl-DBI:S::C2 for perl:5.32, a maintainer when discontinuing perl:5.30 should also to discontinue perl-DBI:S::C1. In that case DNF should not mark perl-DBI:S stream as EOL because there is still another context, C2, under support.

Comment 3 Jaroslav Mracek 2022-08-23 07:05:52 UTC
I am curious. Is there any way that EOL will be handled by the same way in Fedora and RHEL? If not than I am afraid that the priority of implementing a feature is getting low.

Comment 4 Petr Pisar 2022-08-23 08:04:59 UTC
To get the answer, ask RHEL product manager. I can only say "Fedora first".

Comment 5 Vít Ondruch 2022-08-24 10:28:00 UTC
(In reply to Jaroslav Mracek from comment #3)
> I am curious. Is there any way that EOL will be handled by the same way in
> Fedora and RHEL? If not than I am afraid that the priority of implementing a
> feature is getting low.

How is it handled in Fedora?

Comment 6 Ben Cotton 2022-11-29 17:53:43 UTC
This message is a reminder that Fedora Linux 35 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '35'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 35 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Comment 7 Petr Pisar 2022-11-30 09:38:39 UTC
It(In reply to Vít Ondruch from comment #5)
> (In reply to Jaroslav Mracek from comment #3)
> > I am curious. Is there any way that EOL will be handled by the same way in
> > Fedora and RHEL? If not than I am afraid that the priority of implementing a
> > feature is getting low.
> 
> How is it handled in Fedora?

It isn't displayed at all.

Comment 8 Ben Cotton 2023-02-07 15:09:21 UTC
This bug appears to have been reported against 'rawhide' during the Fedora Linux 38 development cycle.
Changing version to 38.

Comment 9 Jaroslav Mracek 2023-08-23 14:37:49 UTC
Due to latest changes about future of Modularity in Fedora, what about to close the issue, because the importance of the request was lowered.

Comment 10 Petr Pisar 2023-08-23 15:14:49 UTC
I'm fine with retracting this feature request.


Note You need to log in before you can comment on or make changes to this bug.