Bug 193623

these are really the same, but due to various tag failures and build system
issues did not build and had to have their release tag increased.

Is this giving problems when upgrading from fcX to fcX+1?

See https://www.redhat.com/archives/fedora-extras-list/2006-May/msg00083.html
for a recipe how old-distro-version-only fixes can be done without breaking the
upgrade path.

I know nothing about nsd but users upgrading from FC-3 to FC-4 (and FC-5, and
devel) will be left with the FC-3 version installed, which may or may not break
due to differing dependencies, and newer distro versions have improved security
features in compilers etc, so situations like this should really be always avoided.

ping

I would consider this a bug in anaconda or the upgrade process. What happens
when packages have the same version number, but are linked against older other
packages (eg glibc).

The above linked solution is also pretty bad. I upgraded nsd to version 2.3.5,
for all FC distributions. So then what? I cannot use sub-releases as suggested,
because all these packages are now nsd-2.3.5. I bumped the release number per FC
distribution, so fc3 has 2.3.5-1, fc4 has 2.3.5-2, fc5 has 2.3.5-3, but this is
really something that should be fixed elsewhere.

(In reply to comment #4)
> What happens
> when packages have the same version number, but are linked against older other
> packages (eg glibc).

If that happens, it's a packaging bug, and the packager needs to fix it.
(I'm assuming by "version number" you mean the NEVRA
(Name-Epoch-Version-Release-Arch) tuple)

> The above linked solution is also pretty bad. I upgraded nsd to version 2.3.5,
> for all FC distributions. So then what? I cannot use sub-releases as 
> suggested, because all these packages are now nsd-2.3.5.

Of course you can.  The linked recipe talks about the *Release* tag; you seem to
be mixing it up with the Version tag.

> I bumped the release number per FC
> distribution, so fc3 has 2.3.5-1, fc4 has 2.3.5-2, fc5 has 2.3.5-3, but this 
> is really something that should be fixed elsewhere.

Using the "disttag" (use the exact same specfile for all/many branches, just
append %{?dist} to the release tag) is one way to deal with this, already done
so by the vast majority of packagers.  In this case it would have probably
sufficed to use 1%{?dist} as the release tag for all branches. 
http://fedoraproject.org/wiki/DistTag

As I was already using disttag, this is obviously not enough, or your original
bug entry was not neccessary/wrong.

Disttag is not enough alone, it cannot "fix" whatever is on the left of it in
the release tag (or the version or the epoch).  That's the packager's
responsibility, and that part was broken before this bug report got resolved.

Sorry about parroting it, but please read through the linked recipe once more
and think about it; it does contain a valid way to prevent problems like this
when done *in advance*.

Just look at the numbers in the initial comment.  My guess is that you initially
pushed 2.3.4-3%{?dist} for all branches, then noticed that all < FC6 versions
needed a fix, so they were bumped to 2.3.4-4%{?dist}.  Later on, the FC3 version
was once more bumped to 2.3.4-5%{?dist}.  Using the linked recipe instead of
bumping the number to the left of %{?dist} would have resulted in this instead
of the one in the initial comment:

  3: 0:2.3.4-3.fc3.2
  4: 0:2.3.4-3.fc4.1
  5: 0:2.3.4-3.fc5.1
  6: 0:2.3.4-3.fc6

...and there would have been no problems; unlike the state which triggered this
bug report, the above is a perfectly valid upgrade path as far as rpm's version
comparison is concerned and all package versions in newer distro versions
cleanly upgrade the ones in older ones.