Description of problem:
After fetching the rhel8 container image and running a shell inside, 'rpm -V' reports that tzdata package is broken. After reinstalling the package, 'rpm -V' reports no error, and processes ontop can use the files from tzdata (in my case '/usr/sbin/php-fpm --nodaemonize').

Version-Release number of selected component (if applicable):
rhel8-beta
Host running the nightly beta, the container-image fetched from registry.access.redhat.com/rhel8-beta .

How reproducible:
always

Steps to Reproduce:
1. setup the rhel8, KVM guest is enough
2. dnf install podman buildah
3. container=$(buildah from registry.access.redhat.com/rhel8-beta)
4. cat >beta.repo<<EOT
[rhel8]
name=rhel8
baseurl=http://<url>/BaseOS/x86_64/os/

[rhel8-AS]
name=rhel8-AS
baseurl=http://<url>/AppStream/x86_64/os/
EOT
5. buildah copy $container ./beta.repo /etc/yum.repos.d/beta.repo
6. buildah run $container -- /usr/bin/bash
7. (on the new shell) rpm -V tzdata

Actual results:
[...]
missing     /usr/share/zoneinfo/posix/America/Marigot
missing     /usr/share/zoneinfo/posix/America/Martinique
missing     /usr/share/zoneinfo/posix/America/Matamoros
missing     /usr/share/zoneinfo/posix/America/Mazatlan
missing     /usr/share/zoneinfo/posix/America/Mendoza
missing     /usr/share/zoneinfo/posix/America/Menominee
[...]

Expected results:
tzdata should be installed properly

Additional info:

- Manually removing tzdata and reinstalling works:
dnf download tzdata
rpm -e --nodeps tzdata
rpm -ivh tzdata

Excerpt from the comments (I might have misunderstood them):
- the rhel8 beta images are removing tzdata files intentionally
- because of https://bugzilla.redhat.com/show_bug.cgi?id=1051816
  That bz seems like it was fixed in 2015 though, I wonder why it
  would be current in rhel8 builds - rhel8 was forked from Fedora
  much later

Any chance to get this fixed for GA, so we can start with a container image where the RPM-db and tzdata contents on disk are matching?  If we do not, people will live with hacks around that (i.e. reinstalling tzdata as part of their setup procedure) for the whole rhel8 livetime.  This will cost time, cycles - and reputation.

Carlos,
    Can you live with the hack in the rhel7-minimal (not much choice at this point, been out there forever) and rhel8-minimal (it would be a change in behavior. I can live with this one, because the minimal image is already hacky with microdnf having to specify all of the repos, etc) images? This is what I am proposing:

rhel7 - no hack
rhel7-minimal - leave hack
rhel8 - remove hack
rhel8-minimal - leave hack
rhel8-init - remove hack

Then, we start a concerted effort for RHEL9 to fix rhel-minimal (and the others) the right way.

Like the rest of the layered images, all rhel8-init should need is to be rebuilt once rhel8:8.0-ondeck is fixed.

(In reply to Scott McCarty from comment #16)
> Carlos,
>     Can you live with the hack in the rhel7-minimal (not much choice at this
> point, been out there forever) and rhel8-minimal (it would be a change in
> behavior. I can live with this one, because the minimal image is already
> hacky with microdnf having to specify all of the repos, etc) images? This is
> what I am proposing:

The minimal images are clearly for use by technical experts you are trying
to minimize the installed size and will thus likely see less questions and
cost from CEE.
 
> rhel7 - no hack
> rhel7-minimal - leave hack
> rhel8 - remove hack
> rhel8-minimal - leave hack
> rhel8-init - remove hack

This looks good to me, it covers rhel8 and rhel8-init which should not have
the hack.

> Then, we start a concerted effort for RHEL9 to fix rhel-minimal (and the
> others) the right way.

Agreed.

(In reply to Carlos O'Donell from comment #18)
> (In reply to Scott McCarty from comment #16)
> > Carlos,
> >     Can you live with the hack in the rhel7-minimal (not much choice at this
> > point, been out there forever) and rhel8-minimal (it would be a change in
> > behavior. I can live with this one, because the minimal image is already
> > hacky with microdnf having to specify all of the repos, etc) images? This is
> > what I am proposing:
> 
> The minimal images are clearly for use by technical experts you are trying
> to minimize the installed size and will thus likely see less questions and
> cost from CEE.
>  
> > rhel7 - no hack
> > rhel7-minimal - leave hack
> > rhel8 - remove hack
> > rhel8-minimal - leave hack
> > rhel8-init - remove hack
> 
> This looks good to me, it covers rhel8 and rhel8-init which should not have
> the hack.
> 
> > Then, we start a concerted effort for RHEL9 to fix rhel-minimal (and the
> > others) the right way.
> 
> Agreed.

Patsy,

As tzdata owner are you OK with leaving the minimal images with stripped
tzdata? The full images will be fixed.

Yes, I'm OK with this.

Thanks!

Sushma - is this a change that RCM needs to make or does Frantisek need to make this change?

(In reply to Laurie Friedman from comment #22)
> Sushma - is this a change that RCM needs to make or does Frantisek need to
> make this change?

Either can do it.  I would recommend Frantisek as the image owner.

*** Bug 1674495 has been marked as a duplicate of this bug. ***

python3-pytz also impacted by this issue.

The better approach for this problem may be packaging of tzdata so that you have a minimal and a full one, and python3-pyzt and other packages that depend on zoneinfo being there can use that subpackage name and correctly get the contents they are wanting, but also allow for a smaller image where things not needed are not included.

(In reply to Laurie Friedman from comment #22)
> Sushma - is this a change that RCM needs to make or does Frantisek need to
> make this change?

Looks like Frantisek took care of it and the fix is VERIFIED by Dave Darrah in https://bugzilla.redhat.com/show_bug.cgi?id=1668185#c31

*** Bug 1903219 has been marked as a duplicate of this bug. ***