On 13. 07. 21 16:31, Carlos O'Donell wrote:
On 7/12/21 12:16 PM, Petr Viktorin wrote:
On 06. 07. 21 20:38, 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.
[...]
Python should work well without *any* tzdata installed. But having
only a small subset of timezones would result in issues unique to
Fedora-based systems (assuming those are the only systems that split
tzdata).
It's possible to remove all tzdata.
However, without *some* data it is not easy to distinguish between these
two scenarios if you want to offer a different error message:
- Is this zone provided and correct but missing? e.g. exists but is not installed.
- zone table exists, lists the zone, but the zone is missing.
- Is this zone not correct? e.g. doesn't exist in the current version.
- zone table doesn't list the zone.
True. But I don't see a use case where this would be important enough:
when is an error message like "tzdata is not installed, so the zone
can't be used *or* checked" not enough?
The problem with making it possible to distinguish between these two
scenarios is that *every* consumer of tzdata must now distinguish
between them. If they assume tzdata is never split (as many do, AFAIK),
their error messages will be wrong.
That's not every consumer we distribute in a RPM (we could handle that I
guess), but also any third-party one people will build/install on their
systems.
We could theoretically patch Python to give reasonable error
messages. But since the consumer of the tz data (the zoneinfo module)
was only added in Python 3.9 (last year), existing applications
mainly use third-party modules instead of the standard library. I
assume that like Python, these modules expect tzinfo to either be
missing entirely or be all there. And I expect this is the case for
more than just Python modules.
Over time some zones become deprecated and invalid names.
One must already handle zone name changes, so if the code can handle
name deprecation then it will report the same error for missing zoneinfo. >
Is it reasonable for glibc to hardcode the +0 fallback timezone,
rather than needing the zoneinfo file for it? If so, we could remove
tzdata from minimal containers entirely. Or is that too naive?
It is not naive.
glibc already falls back to UTC with no data present (and we need to cleanup
what we print).
The question is what kind of errors we want to be able to express to users.
== 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?
Slightly more (based on experience).
* UTC
/usr/share/zoneinfo/UTC
* Zone tables (which can be used to determine what is valid).
/usr/share/zoneinfo/iso3166.tab
/usr/share/zoneinfo/zone.tab
/usr/share/zoneinfo/zone1970.tab
* License file
/usr/share/licenses/tzdata/LICENSE
It saves ~5MiB for base container image sizes in a supportable way
(as opposed to what is done today which is to delete the zoneinfo 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.
For python3-libs, I would have no issue with tzdata a weak dependency.
For users of python3-dateutil, I'd suggest using the Python standard library instead, where possible.
The split today is self-contained.
Eventually we want to allow tzdata-minimal to be the only requirement
for a functional system (fedora-minimal containers).
By default we want all of tzdata to be installed (default fedora host
install).
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
