m (→How To Test) |
mNo edit summary |
||
Line 43: | Line 43: | ||
== Detailed Description == | == Detailed Description == | ||
This is the first step towards providing support for a minimal, UTC only version of tzdata for containers. The tzdata-minimal package will be a stand-alone, UTC only subset of tzdata. The tzdata package will require tzdata-minimal. | This is the first step towards providing support for a minimal, UTC only, version of tzdata for containers. The tzdata-minimal package will be a stand-alone, UTC only, subset of tzdata. The tzdata package will require tzdata-minimal. | ||
With this framework in place, other packages can develop code to detect a minimal tzdata installation. These packages will also need to provide appropriate messages when users request timezone information not | With this framework in place, other packages can develop code to detect a minimal tzdata installation. These packages will also need to provide appropriate messages when users request timezone information not available when only tzdata-minimal is installed. | ||
== Feedback == | == Feedback == | ||
We have had requests for this functionality in order to support minimal container installations. Currently some container kickstart installations already remove most of the timezone information provided by tzdata, leaving only UTC support available. | We have had requests for this functionality in order to support minimal container installations. Currently some container kickstart installations already ad hoc remove most of the timezone information provided by tzdata, leaving only UTC support available. This change provides a formal method of providing this support. | ||
Both the glibc and python teams are aware of this proposed change. This change does not currently require changes in their code. The goal is for those packages that currently require tzdata as part of their build or install, move towards recommending tzdata instead. | Both the glibc and python teams are aware of this proposed change. This change does not currently require changes in their code. The goal is for those packages that currently require tzdata as part of their build or install, move towards recommending tzdata instead. | ||
Line 99: | Line 99: | ||
== User Experience == | == User Experience == | ||
Users will see that new updates to tzdata include a new package dependency on tzdata-minimal. | |||
<!-- If this change proposal is noticeable by users, how will their experiences change as a result? | <!-- If this change proposal is noticeable by users, how will their experiences change as a result? | ||
Line 111: | Line 112: | ||
== Dependencies == | == Dependencies == | ||
This change does not require or depend on changes to other packages. However, we hope that dependent packages will work towards recommending tzdata for builds and installs rather than requiring it. | |||
<!-- What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this change depends? In other words, completion of another change owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like the kernel (if this is not a kernel change)? --> | <!-- What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this change depends? In other words, completion of another change owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like the kernel (if this is not a kernel change)? --> | ||
Line 117: | Line 119: | ||
== Contingency Plan == | == Contingency Plan == | ||
If we are unable to complete this feature by the final development freeze, we will revert to the shipped configuration. | |||
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --> | <!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --> | ||
* Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
Line 127: | Line 129: | ||
== Documentation == | == Documentation == | ||
No documentation changes are needed at this time. | |||
<!-- Is there upstream documentation on this change, or notes you have written yourself? Link to that material here so other interested developers can get involved. --> | <!-- Is there upstream documentation on this change, or notes you have written yourself? Link to that material here so other interested developers can get involved. --> | ||
Line 133: | Line 136: | ||
== Release Notes == | == Release Notes == | ||
The tzdata package is now divided into a UTC only package, tzdata-minimal, and tzdata. | |||
<!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --> | <!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --> | ||
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this change, indicate them here. A link to upstream documentation will often satisfy this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. | <!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this change, indicate them here. A link to upstream documentation will often satisfy this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. |
Revision as of 12:20, 28 June 2021
Change Proposal Name
tzdata-minimal
Summary
Split the tzdata package into two parts - tzdata and tzdata-minimal. tzdata will require tzdata-minimal. tzdata-minimal provides the minimal files needed to support UTC on containers.
Owner
- Name: Patsy Griffin (Franklin)
- Email: patsy@redhat.com
Current status
- Targeted release: 35
- Last updated: 2021-06-28
- FESCo issue: <will be assigned by the Wrangler>
- Tracker bug: <will be assigned by the Wrangler>
- Release notes tracker: <will be assigned by the Wrangler>
Detailed Description
This is the first step towards providing support for a minimal, UTC only, version of tzdata for containers. The tzdata-minimal package will be a stand-alone, UTC only, subset of tzdata. The tzdata package will require tzdata-minimal.
With this framework in place, other packages can develop code to detect a minimal tzdata installation. These packages will also need to provide appropriate messages when users request timezone information not available when only tzdata-minimal is installed.
Feedback
We have had requests for this functionality in order to support minimal container installations. Currently some container kickstart installations already ad hoc remove most of the timezone information provided by tzdata, leaving only UTC support available. This change provides a formal method of providing this support.
Both the glibc and python teams are aware of this proposed change. This change does not currently require changes in their code. The goal is for those packages that currently require tzdata as part of their build or install, move towards recommending tzdata instead.
Benefit to Fedora
This change will reduce the size of base container installations.
Scope
- Proposal owners: Implement the proposal.
- Other developers: Developers need to ensure that their packages continue to build and install with the new split tzdata/tzdata-minimal package changes.
- Release engineering: The tzdata maintainer will ensure that the package builds and passes all tests on F35.
- Policies and guidelines: The policies and guidelines do not need to be updated.
- Trademark approval: N/A (not needed for this Change)
- Alignment with Objectives: This change is directly related to container minimization goals.
Upgrade/compatibility impact
The only visible change will be a new package tzdata-minimal required by tzdata.
How To Test
Run a dnf upgrade of tzdata and observe that tzdata-minimal is now also installed as a dependency.
User Experience
Users will see that new updates to tzdata include a new package dependency on tzdata-minimal.
Dependencies
This change does not require or depend on changes to other packages. However, we hope that dependent packages will work towards recommending tzdata for builds and installs rather than requiring it.
Contingency Plan
If we are unable to complete this feature by the final development freeze, we will revert to the shipped configuration.
- Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
- Contingency deadline: N/A (not a System Wide Change)
- Blocks release? N/A (not a System Wide Change), Yes/No
Documentation
No documentation changes are needed at this time.
N/A (not a System Wide Change)
Release Notes
The tzdata package is now divided into a UTC only package, tzdata-minimal, and tzdata.