From Fedora Project Wiki
(Change withdrawn https://pagure.io/fesco/issue/2647#comment-744857)
 
(8 intermediate revisions by 2 users not shown)
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 -->
<!-- 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 ==
== Summary ==
Line 28: Line 24:
<!-- Select proper category, default is Self Contained Change -->
<!-- Select proper category, default is Self Contained Change -->
[[Category:SelfContainedChange]]
[[Category:SelfContainedChange]]
<!-- [[Category:SystemWideChange]] -->


* 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}}  
* 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  
<!-- 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
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>
* Tracker bug: <will be assigned by the Wrangler>
* Release notes tracker: <will be assigned by the Wrangler>
* Release notes tracker: <will be assigned by the Wrangler>


== 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 provided by 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 ==
== 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 57: Line 53:
== Scope ==
== Scope ==
* Proposal owners: Implement the proposal.
* 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.
* 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.
* Policies and guidelines: The policies and guidelines do not need to be updated.
* Trademark approval: N/A (not needed for this Change)
* 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 ==
== Upgrade/compatibility impact ==
Line 99: Line 87:


== 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 100:


== 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 107:


== Contingency Plan ==
== Contingency Plan ==
 
* 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), Yes/No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 


== Documentation ==
== Documentation ==
<!-- 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. -->
No documentation changes are needed at this time.  


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
N/A (not a System Wide Change)


== 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.  

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.