Latest revision as of 14:23, 26 July 2021

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: Fedora Linux 35
Last updated: 2021-07-26
FESCo issue: #2647
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: No coordination required with Release Engineering.
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: N/A

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

Contingency mechanism: If we are unable to complete this feature by the final development freeze, we will revert to the shipped configuration.
Contingency deadline: 100% Code complete deadline
Blocks release? No

Documentation

No documentation changes are needed at this time.

Release Notes

The tzdata package is now divided into a UTC only package, tzdata-minimal, and tzdata.

@@ Line 1: / Line 1: @@
-{{admon/important | Comments and Explanations | The page source contains comments providing guidance to fill out each section. They are invisible when viewing this page. To read it, choose the "view source" link.<br/> '''Copy the source to a ''new page'' before making changes!  DO NOT EDIT THIS TEMPLATE FOR YOUR CHANGE PROPOSAL.'''}}
-{{admon/tip | Guidance | For details on how to fill out this form, see the [https://docs.fedoraproject.org/en-US/program_management/changes_guide/ documentation].}}
 <!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name.  This keeps all change proposals in the same namespace -->
-= Change Proposal Name =
+= tzdata-minimal =
-tzdata-minimal
 == Summary ==
@@ Line 20: / Line 16: @@
 == Current status ==
-Category:ChangePageIncomplete
+[[Category:ChangePageIncomplete]]
 <!-- When your change proposal page is completed and ready for review and announcement -->
 <!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
@@ Line 27: / Line 23: @@
 <!-- Select proper category, default is Self Contained Change -->
-Category:SelfContainedChange
+[[Category:SelfContainedChange]]
-* Targeted release: 35
+* Targeted release: Fedora Linux 35
 * Last updated: <!-- this is an automatic macro — you don't need to change this line -->  {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}
 <!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page
@@ Line 38: / Line 34: @@
 ON_QA -> change is fully code complete
 -->
-* FESCo issue: <will be assigned by the Wrangler>
+* FESCo issue: [https://pagure.io/fesco/issue/2647 #2647]
 * Tracker bug: <will be assigned by the Wrangler>
 * Release notes tracker: <will be assigned by the Wrangler>
@@ Line 57: / Line 53: @@
 == Scope ==
 * Proposal owners: Implement the proposal.
-<!-- What work do the feature owners have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
 * 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.
+* Release engineering: No coordination required with Release Engineering.
-[https://pagure.io/releng/issues #Releng issue number] <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
-<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuild required?  include a link to the releng issue.
-The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication -->
 * 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: N/A
-* Alignment with Objectives: This change is directly related to container minimization goals.
 == Upgrade/compatibility impact ==
@@ Line 119: / Line 107: @@
 == Contingency Plan ==
-If we are unable to complete this feature by the final development freeze, we will revert to the shipped configuration.
+* Contingency mechanism: 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.  -->
+* Contingency deadline: 100% Code complete deadline
-* Contingency mechanism: (What to do?  Who will do it?) N/A (not a System Wide Change)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
+* Blocks release? No
-<!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
-* Contingency deadline: N/A (not a System Wide Change)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
-<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? -->
-* Blocks release? N/A (not a System Wide Change), No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 == 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. -->
-<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
-N/A (not a System Wide Change)
 == Release Notes ==

Search

Changes/tzdata-minimal: Difference between revisions