tzdata packaging options

tzdata packaging options

[Brian Inglis]

Hi folks,

I have been building and distributing tzdata with maximal backward compatibility 
since adopting the package.

The maintainer and some distros are choosing to consolidate data and drop 
historical details since 1970.
I question whether there are any Cygwin users who use and need the TAI-offset 
including leap seconds zoneinfo/right subtree, and whether we also need to 
include the zoneinfo/posix subtree, duplicating the data in the main zoneinfo tree?

There could be astrologers, genealogists, modern-history historians, and 
developers of related software who use the complete historical details, and 
astronomers, physicists, who use the TAI-offset including leap seconds 
zoneinfo/right subtree.

I am unsure if anyone depends on the posix subtree duplicating the main tree.

I could split the current package into the main tree and the "posix" subtree 
each 1.7MB, and the "right" subtree 2.3MB.

For tzdata-minimal, which could become the Base package, I could generate 
another build with only zones consolidated with common history since 1970, but 
that would require another build with different options to generate the data to 
compile, so presumably another source package, unless there is a way to generate 
say a minimal subtree with another cygmake with different MAKEOPTS, and have it 
packaged the same as the main subtree, or could cygport go bananas?

Fedora was developing a tzdata-minimal package, which was only to include UTC 
for containers, but it looks like  UTC-only should work by not installing *ANY* 
tzdata, so they shelved their efforts:

	https://fedoraproject.org/wiki/Changes/tzdata-minimal
	https://bugzilla.redhat.com/buglist.cgi?component=tzdata&product=Fedora

Do we think there could be a use case for a UTC-only (Base?) no tzdata package 
e.g. CI, and the no data defaults will be handled adequately?

For RH see RHEL Timezone Data (tzdata) - Development Status Page:

	https://access.redhat.com/articles/1187353

Suggestions for how best to proceed with these options, and to ask these 
questions of users on the main list?

-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer     but when there is no more to cut
                                 -- Antoine de Saint-Exupéry

Re: tzdata packaging options

[Adam Dinwoodie]

On Tue, 17 Oct 2023 at 23:48, Brian Inglis via Cygwin-apps
<cygwin-apps@cygwin.com> wrote:
>
> Hi folks,
>
> I have been building and distributing tzdata with maximal backward compatibility
> since adopting the package.
>
> The maintainer and some distros are choosing to consolidate data and drop
> historical details since 1970.
> I question whether there are any Cygwin users who use and need the TAI-offset
> including leap seconds zoneinfo/right subtree, and whether we also need to
> include the zoneinfo/posix subtree, duplicating the data in the main zoneinfo tree?
>
> There could be astrologers, genealogists, modern-history historians, and
> developers of related software who use the complete historical details, and
> astronomers, physicists, who use the TAI-offset including leap seconds
> zoneinfo/right subtree.
>
> I am unsure if anyone depends on the posix subtree duplicating the main tree.
>
> I could split the current package into the main tree and the "posix" subtree
> each 1.7MB, and the "right" subtree 2.3MB.
>
> For tzdata-minimal, which could become the Base package, I could generate
> another build with only zones consolidated with common history since 1970, but
> that would require another build with different options to generate the data to
> compile, so presumably another source package, unless there is a way to generate
> say a minimal subtree with another cygmake with different MAKEOPTS, and have it
> packaged the same as the main subtree, or could cygport go bananas?
>
> Fedora was developing a tzdata-minimal package, which was only to include UTC
> for containers, but it looks like  UTC-only should work by not installing *ANY*
> tzdata, so they shelved their efforts:
>
>         https://fedoraproject.org/wiki/Changes/tzdata-minimal
>         https://bugzilla.redhat.com/buglist.cgi?component=tzdata&product=Fedora
>
> Do we think there could be a use case for a UTC-only (Base?) no tzdata package
> e.g. CI, and the no data defaults will be handled adequately?
>
> For RH see RHEL Timezone Data (tzdata) - Development Status Page:
>
>         https://access.redhat.com/articles/1187353
>
> Suggestions for how best to proceed with these options, and to ask these
> questions of users on the main list?

I expect that – while I use Cygwin in CI contexts – that's relatively
rare, and most folk using Cygwin will be using it directly. I expect
not having at least a core of tzdata files available by default would
cause some considerable confusion for those users, as I imagine lots
of them consume data from those packages without realising they're
doing so. If Cygwin's setup and dependency resolution tools had, say,
the equivalent of Debian's task package groups and/or
Recommends/Suggests dependencies, it might be sensible to have tzdata
recommended for desktop use but not required for server use. Until and
unless those enhancements happen, though, IMVHO at least a core tzdata
package should be part of the base installation.

That said, I suspect there's very few people who need all the
extensive data, and those people probably know they're doing something
a bit weird, so moving the "posix" and/or "right" trees into separate
packages seems reasonable. (Although if "posix" is just a duplicate of
the main tree, wouldn't that actually make things worse? If they're
duplicated in the same package, I'd expect them to at least be
well-compressed, and potentially to be hardlinks so the additional
space from including both is near-zero…)

_That_ said, given the relatively cheap costs of disk space and
bandwidth, I don't see much value in shaving a few MB here and there
when this is still a relatively small part of most Cygwin
installations. So overall I'd be inclined to do whatever is the least
work that's not going to break things.

FWIW, if you wanted to canvass opinions from the wider list, I think
the email you've sent here would be fine for that purpose, although
I'd probably remove the implementation details (e.g. the discussions
of cygmake) and just list the options available and the different
impacts thereof.