12:20 p.m.
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: patsy(a)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.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1:38 p.m.
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: patsy(a)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?
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.
Thanks,
--
David Cantrell <dcantrell(a)redhat.com>
Red Hat, Inc. | Boston, MA | EST5EDT
11:16 a.m.
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.
>
> == Owner ==
> * Name: Patsy Griffin (Franklin)
> * Email: patsy(a)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.
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).
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.
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?
> == 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?
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.
11:31 a.m.
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: patsy(a)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.
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.
--
Cheers,
Carlos.
7:12 a.m.
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: patsy(a)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.
9:31 a.m.
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.
>>
>> == Owner ==
>> * Name: Patsy Griffin (Franklin)
>> * Email: patsy(a)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.
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.
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).
--
Cheers,
Carlos.
10:17 a.m.
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).
3:41 p.m.
On 7/13/21 11:17 AM, Petr Viktorin wrote:
On 13. 07. 21 16:31, Carlos O'Donell wrote:
> 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?
It may be enough.
If it turns out to be not enough would we be ready to reconsider the
packaging decision?
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.
Understood.
(1) Missing files vs. No /usr/share/zoneinfo.
All existing third-party software must handle zone name changes today,
so there must be some way to handle the error that a given zone is
missing (changed names).
Let me talk a bit about the new C++ time zone API I have been looking
at with Jonathan Wakely.
Errors based on this will be likely correct e.g. get_tz_dir() from the
currently proposed C++ API for this (see (2)):
353 CONSTDATA auto tz_dir_default = "/usr/share/zoneinfo";
354 CONSTDATA auto tz_dir_buildroot = "/usr/share/zoneinfo/uclibc";
355
356 // Check special path which is valid for buildroot with uclibc builds
357 if(stat(tz_dir_buildroot, &sb) == 0 && S_ISDIR(sb.st_mode))
358 return tz_dir_buildroot;
359 else if(stat(tz_dir_default, &sb) == 0 && S_ISDIR(sb.st_mode))
360 return tz_dir_default;
361 else
362 throw runtime_error("discover_tz_dir failed to find zoneinfo\n");
Having tzdata uninstalled will throw the generic error as on line 362.
But having tzdata-minimal will instead throw a specific error from line 3624:
3624 throw std::runtime_error(std::string(tz_name) + " not found in timezone
database");
This probably supports having tzdata removed entirely, since the latter
error makes it seems as-if the zone name is wrong (it's not, it's just
not installed).
Notes:
https://github.com/HowardHinnant/date
(2) Non-rpm packaging.
We have C++ users using Howard Hinnart's 'date' package that implements
<chrono> header and it can process complete IANA tzdb files.
Currently Howard's API is being proposed for inclusion
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0355r7.html
So the error returned in the runtime_error can have an explanatory string,
so it could be tailored to a system with a partially installed tzdata-minimal,
but it could likewise detect the entire tzdata is uninstalled (no files)
and just say that (as you note, and the code supports today).
So there may not be a strong case for making the distinction between the
two error modes.
>> 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).
>
--
Cheers,
Carlos.
3:42 p.m.
On 7/13/21 8:12 AM, Petr Viktorin wrote:
On 12. 07. 21 18:31, Carlos O'Donell wrote:
> 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.
That's a fair point. We'll get clarification from upstream and Paul Eggert.
--
Cheers,
Carlos.
5:43 a.m.
On Tue, 13 Jul 2021 at 21:42, Carlos O'Donell wrote:
(1) Missing files vs. No /usr/share/zoneinfo.
All existing third-party software must handle zone name changes today,
so there must be some way to handle the error that a given zone is
missing (changed names).
Let me talk a bit about the new C++ time zone API I have been looking
at with Jonathan Wakely.
Errors based on this will be likely correct e.g. get_tz_dir() from the
currently proposed C++ API for this (see (2)):
N.B. The functions below are not part of the standardized API, they
are implementation details of a specific implementation of that API.
353 CONSTDATA auto tz_dir_default = "/usr/share/zoneinfo";
354 CONSTDATA auto tz_dir_buildroot = "/usr/share/zoneinfo/uclibc";
355
356 // Check special path which is valid for buildroot with uclibc builds
357 if(stat(tz_dir_buildroot, &sb) == 0 && S_ISDIR(sb.st_mode))
358 return tz_dir_buildroot;
359 else if(stat(tz_dir_default, &sb) == 0 && S_ISDIR(sb.st_mode))
360 return tz_dir_default;
361 else
362 throw runtime_error("discover_tz_dir failed to find zoneinfo\n");
Having tzdata uninstalled will throw the generic error as on line 362.
But having tzdata-minimal will instead throw a specific error from line 3624:
3624 throw std::runtime_error(std::string(tz_name) + " not found in timezone
database");
This probably supports having tzdata removed entirely, since the latter
error makes it seems as-if the zone name is wrong (it's not, it's just
not installed).
Notes:
https://github.com/HowardHinnant/date
(2) Non-rpm packaging.
We have C++ users using Howard Hinnart's 'date' package that implements
<chrono> header and it can process complete IANA tzdb files.
Currently Howard's API is being proposed for inclusion
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0355r7.html
N.B. This is incorrect, it was proposed some years ago (the paper
above is from 2018) and is now part of ISO/IEC 14882:2020 i.e. the
C++20 standard.
I'm not yet sure what the C++ runtime will need to do if there are no
zoneinfo files at all, not even UTC. I suspect we will need a fallback
to UTC as well, and std::tzdb::current_zone() will return the info for
the UTC timezone. So I'm not sure that there's much practical
difference between no tzdata at all and tzdata-minimal as far as
libstdc++ will be concerned. This might change once I actually start
to implement it though. Maybe having tzdata-minimal would allow the
initial implementation to omit the fallback (assuming that all
sensible linux environments have at least UTC info), and add the
fallback later.
(It doesn't help that glibc has a fallback to UTC because the C++
runtime can't use glibc for timezone info, it will consume the tzdata
files directly.)
3:38 a.m.
On 14. 07. 21 12:43, Jonathan Wakely wrote:
On Tue, 13 Jul 2021 at 21:42, Carlos O'Donell wrote:
> (1) Missing files vs. No /usr/share/zoneinfo.
>
> All existing third-party software must handle zone name changes today,
> so there must be some way to handle the error that a given zone is
> missing (changed names).
>
> Let me talk a bit about the new C++ time zone API I have been looking
> at with Jonathan Wakely.
>
> Errors based on this will be likely correct e.g. get_tz_dir() from the
> currently proposed C++ API for this (see (2)):
N.B. The functions below are not part of the standardized API, they
are implementation details of a specific implementation of that API.
>
> 353 CONSTDATA auto tz_dir_default = "/usr/share/zoneinfo";
> 354 CONSTDATA auto tz_dir_buildroot = "/usr/share/zoneinfo/uclibc";
> 355
> 356 // Check special path which is valid for buildroot with uclibc builds
> 357 if(stat(tz_dir_buildroot, &sb) == 0 && S_ISDIR(sb.st_mode))
> 358 return tz_dir_buildroot;
> 359 else if(stat(tz_dir_default, &sb) == 0 && S_ISDIR(sb.st_mode))
> 360 return tz_dir_default;
> 361 else
> 362 throw runtime_error("discover_tz_dir failed to find
zoneinfo\n");
>
> Having tzdata uninstalled will throw the generic error as on line 362.
>
> But having tzdata-minimal will instead throw a specific error from line 3624:
>
> 3624 throw std::runtime_error(std::string(tz_name) + " not found in
timezone database");
>
> This probably supports having tzdata removed entirely, since the latter
> error makes it seems as-if the zone name is wrong (it's not, it's just
> not installed).
>
> Notes:
> https://github.com/HowardHinnant/date
>
> (2) Non-rpm packaging.
>
> We have C++ users using Howard Hinnart's 'date' package that implements
> <chrono> header and it can process complete IANA tzdb files.
>
> Currently Howard's API is being proposed for inclusion
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0355r7.html
N.B. This is incorrect, it was proposed some years ago (the paper
above is from 2018) and is now part of ISO/IEC 14882:2020 i.e. the
C++20 standard.
I'm not yet sure what the C++ runtime will need to do if there are no
zoneinfo files at all, not even UTC. I suspect we will need a fallback
to UTC as well, and std::tzdb::current_zone() will return the info for
the UTC timezone. So I'm not sure that there's much practical
difference between no tzdata at all and tzdata-minimal as far as
libstdc++ will be concerned. This might change once I actually start
to implement it though. Maybe having tzdata-minimal would allow the
initial implementation to omit the fallback (assuming that all
sensible linux environments have at least UTC info), and add the
fallback later.
(It doesn't help that glibc has a fallback to UTC because the C++
runtime can't use glibc for timezone info, it will consume the tzdata
files directly.)
It doesn't help Python's zoneinfo either, for the same reason.
I assume anything that uses the glibc API shouldn't depend on tzdata
directly.
5:34 a.m.
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: patsy(a)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.
In general, I like the idea of making it easier to not install tzdata.
For many machines it's completely unnecessary, and 5MB is enough to
make this worthwhile.
I don't know enough about all the consumers to comment on the details.
FWIW, systemd-timedated already has a reasonable message that encompasses
both possible errors:
$ timedatectl set-timezone Europe/Warsaw2
Failed to set time zone: Invalid or not installed time zone 'Europe/Warsaw2'
But I think it'd be useful to use a different message if we can
distinguish the two cases. I'd be happy to take a patch...
Zbyszek
1:33 p.m.
On 7/15/21 6:34 AM, Zbigniew Jędrzejewski-Szmek 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: patsy(a)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.
In general, I like the idea of making it easier to not install tzdata.
For many machines it's completely unnecessary, and 5MB is enough to
make this worthwhile.
Thanks for supporting the idea.
I don't know enough about all the consumers to comment on the
details.
FWIW, systemd-timedated already has a reasonable message that encompasses
both possible errors:
$ timedatectl set-timezone Europe/Warsaw2
Failed to set time zone: Invalid or not installed time zone 'Europe/Warsaw2'
But I think it'd be useful to use a different message if we can
distinguish the two cases. I'd be happy to take a patch...
Yes, you could say "invalid" (zone table files installed) if the zone is not
in one of the tables, and "invalid or not installed" if there are no files
(no tzdata installed).
We are still in the process of checking with upstream tzdata if they are
comfortable with, and will support *not* installing some of the zones, and
document that upstream.
--
Cheers,
Carlos.
7:39 a.m.
On 15. 07. 21 20:33, Carlos O'Donell wrote:
On 7/15/21 6:34 AM, Zbigniew Jędrzejewski-Szmek 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: patsy(a)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.
>
> In general, I like the idea of making it easier to not install tzdata.
> For many machines it's completely unnecessary, and 5MB is enough to
> make this worthwhile.
Thanks for supporting the idea.
> I don't know enough about all the consumers to comment on the details.
> FWIW, systemd-timedated already has a reasonable message that encompasses
> both possible errors:
>
> $ timedatectl set-timezone Europe/Warsaw2
> Failed to set time zone: Invalid or not installed time zone
'Europe/Warsaw2'
>
> But I think it'd be useful to use a different message if we can
> distinguish the two cases. I'd be happy to take a patch...
Yes, you could say "invalid" (zone table files installed) if the zone is not
in one of the tables, and "invalid or not installed" if there are no files
(no tzdata installed).
Without the split (i.e. if either all or none of tzdata is installed),
it would be similar:
If a zone1970.tab exists but doesn't list the zone (or, hopefully
equivalently: a zone1970.tab exists but there's no file for the zone):
it's "Invalid time zone".
If the table doesn't exist: it's "Invalid or not installed".
We are still in the process of checking with upstream tzdata if they
are
comfortable with, and will support *not* installing some of the zones, and
document that upstream.
9:24 a.m.
This proposal has been withdrawn.
https://pagure.io/fesco/issue/2647#comment-744857
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1005
days inactive
1025
days old
14 comments
6 participants
participants (6)
-
Ben Cotton -
Carlos O'Donell -
David Cantrell -
Jonathan Wakely -
Petr Viktorin -
Zbigniew Jędrzejewski-Szmek