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