On 12. 07. 21 18:31, Carlos O'Donell wrote:
On 7/6/21 2:38 PM, David Cantrell wrote:
On Tue, Jul 06, 2021 at 01:20:47PM -0400, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/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: pa...@redhat.com
== 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.
What is supposed to be in tzdata-minimal? Is it
/usr/share/zoneinfo/UTC or that and more?
A little more is provided.
You need some of the name tables for certain use cases.
What are the use cases (and why are they needed for minimal containers)?
This is based on Intel's clear linux work in splitting the data.
Forcibly removing tzdata on a fresh Fedora VM that I just set up has
the system fall back to UTC, as expected. On this incredibly small
install, tzdata is required glibc-common, python3-libs, and
python3-dateutil. The last one is reasonable, but for all of them I
ask if tzdata is actually a hard dependency or if it can become a weak
dependency and this change proposal could become "make tzdata
something easily removable" rather than creating more tzdata packages.
If you can minimally provide the tables of possible zones, and provide
an easy way to detect a zone is missing, then the APIs can determine:
"Yes you could do that, but your system is missing the data."
vs.
"That is an invalid zone."
Which is a useful distinction.
Sure, we can provide such an API, but that alone won't make consumers
use it. Especially if it's specific to Fedora (and Clear Linux -- AFAIK,
people expect missing bits and pieces are there.)
I think the best place to discuss and document this would be the tz. If
their README (or just a mail thread) said the data can be split this
way, and hinted at what should be done when it is, we wouldn't need this
conversation.
Without that, I don't think it's OK to allow Fedora systems with only
tzdata-minimal.
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
