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.
_______________________________________________
devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
