[tz] Getting current tzdb version in use

[Robert Elz]

    Date:        Sat, 21 Jul 2018 02:08:20 -0400
    From:        Tom Lane <tgl at sss.pgh.pa.us>
    Message-ID:  <8508.1532153300 at sss.pgh.pa.us>

  | And your point is?  Should I conclude that NetBSD users see a seriously
  | lobotomized set of time zones,

No.

  | or does the packager just automatically
  | update the distribution list every time a new file shows up there?

Not that either.    I am the "packager" (currently) and new files only
appear when they have some value.   A new zone with new time
translation data has that value.   Other random files (perhaps) do not.

Further we do not use the upstream (ie: Paul's) Makefiles at all.
(Not for tzdata, and not for tzcode - the latter of which requires
much more manual integration (not by me) as we do not ship the
upstream code unaltered.)   Paul's Makefiles might not even work
with NetBSD's make (I haven't tried them to find out).

  | In my former life as a packager for Red Hat, you'd list a specific set of
  | files you expected your package to install into, say, /usr/bin -- either
  | an unexpected addition or unexpected removal there should set off alarm
  | bells.

Same here.

  | But the file list for tzdb's database would almost certainly just
  | be "/usr/share/zoneinfo/*";

We have no such concept.   Every file is listed individually - which is
needed, if for no other reason, than that we know when something is
removed, and a user upgrades (from however ancient a previous version)
that we automatically remove the no-longer needed file, if it has not been
changed at the user's site, and warn the local management if they have
changed files which are no longer required -- if any of those were found).

If all we expected was '*' then we'd have no way of knowing that some file
should no longer be there - and while time zones themselves are very unlikey
to ever be removed, or renamed (without being replaced by something) these
extra files that you're anticipating being automatically added have no such
requirements.

With this, do remember that with NetBSD many (it was once "most", possibly
not any more, as sad as that is) users upgrade from source, not from binary
distributions.  That is, the "build from source" system needs to handle any
random crap it might find lying around the destination (which cannot assumed
to be empty, or just upgrading what has changed would not really work...)

  | there is no value in expending packager brain
  | cells on second-guessing the upstream there.

The few times a year it happens, and with knowing from the list
what is expected to be changing, and what is not, the intellectual
demands are not something I worry about.

  | Maybe NetBSD's packaging toolchain is too impoverished to do that,
  | but I'd certainly call that a bug not a feature.

You are welcome to your opinion.   I do not share it.

kre