I recently encountered a classic YUM/DNF cache issue where one client couldn't see newly added packages while others could. Let me share the full diagnostic process and solution.

First, verify the package exists in the repository metadata:

# Check server-side repodata
grep "perl-Excel-Writer-XLSX" /path/to/repo/repodata/*-primary.xml.gz

# Alternative client-side check
repoquery --repoid=int-optional-latest --all | grep "perl-Excel-Writer-XLSX"

The standard yum clean expire-cache might not always be sufficient. Try these nuclear options:

# Complete cache wipe
sudo yum clean all

# Alternative for DNF systems
sudo dnf clean all --enablerepo='*'

When cache clearing doesn't work, check these network aspects:

# Verify DNS resolution consistency
dig +short yum.example.com

# Check HTTP access to metadata files
curl -I http://yum.example.com/path/to/repo/repodata/repomd.xml

Examine the client's repo configuration for anomalies:

# Check enabled repos
yum repolist all

# Verify repo file contents
cat /etc/yum.repos.d/internal-repos.repo

# Sample working repo config:
[int-optional-latest]
name=Internal Optional Latest
baseurl=http://yum.example.com/path/to/repo
enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-INTERNAL

Clock skew can cause SSL/TLS verification failures:

# Check time sync status
timedatectl status

# Force NTP sync
sudo chronyc -a makestep

On the repository server, verify filesystem health:

# Check for disk space issues
df -h /path/to/repo

# Verify inode availability
df -i /path/to/repo

# Force filesystem sync
sync

After exhausting all other options, this combination worked:

# Client side
sudo rm -rf /var/cache/yum/*
sudo yum clean all
sudo yum makecache

# Server side
sudo createrepo --update /path/to/repo
sudo restorecon -Rv /path/to/repo

In our RHEL-based environment, we maintain a sophisticated YUM repository structure with multiple channels including:

int-optional-latest/ (disabled by default)
stable/ (production repo)
testing/ (pre-production)

The issue emerged when attempting to install perl-Excel-Writer-XLSX from our int-optional-latest repository. Despite confirming the package existed server-side via:

repoquery -q --repoid=int-optional-latest -l perl-Excel-Writer-XLSX

The client machine stubbornly claimed the package was unavailable.

We performed standard diagnostics:

# Clear YUM cache
sudo yum clean expire-cache
sudo yum clean metadata

# Verify repository configuration
cat /etc/yum.repos.d/internal.repo | grep -A5 "int-optional-latest"

# Check network connectivity
ping yum.example.com
curl -I http://yum.example.com/repos/int-optional-latest/repodata/repomd.xml

While comparing working vs non-working systems, we discovered a critical difference in DNS resolution patterns. The problematic system had:

# Old DNS cache (systemd-resolved)
sudo systemd-resolve --statistics | grep "Cache"

The solution involved flushing multiple cache layers:

# Full cache cleanup sequence
sudo yum clean all
sudo systemd-resolve --flush-caches
sudo rm -rf /var/cache/yum/*
sudo rm -rf /var/lib/yum/yumdb/*

To properly validate repository health, we implemented this verification script:

#!/bin/bash
REPO_URL="http://yum.example.com/repos/int-optional-latest"
TEMPDIR=$(mktemp -d)

wget -q -r -l1 -np -nd -P $TEMPDIR $REPO_URL/repodata/
if ! ls $TEMPDIR/*primary.sqlite* &> /dev/null; then
    echo "ERROR: Missing primary metadata"
    exit 1
fi

sqlite3 $TEMPDIR/*primary.sqlite* "SELECT name FROM packages WHERE name LIKE '%Excel-Writer-XLSX%'" | grep -q Excel
if [ $? -ne 0 ]; then
    echo "ERROR: Package not in metadata"
    exit 1
fi

echo "Repository metadata validated successfully"
rm -rf $TEMPDIR

We enhanced our client-side configuration with these YUM options in /etc/yum.conf:

[main]
metadata_expire=30m
http_caching=packages
deltarpm=0

And implemented this daily cron job for cache maintenance:

0 3 * * * root /usr/bin/yum clean expire-cache && systemd-resolve --flush-caches