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.
