Bug 193623 - nsd: broken upgrade path
nsd: broken upgrade path
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: nsd (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: Paul Wouters
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-05-31 02:45 EDT by Ville Skyttä
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version: 2.3.5-x
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-06-27 12:23:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ville Skyttä 2006-05-31 02:45:22 EDT
There are newer versions of nsd in older distro branches:

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

The FC-3 one is newer than all the others.
Comment 1 Paul Wouters 2006-05-31 03:35:41 EDT
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?
Comment 2 Ville Skyttä 2006-05-31 13:43:15 EDT
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.
Comment 3 Ville Skyttä 2006-06-18 03:37:48 EDT
ping
Comment 4 Paul Wouters 2006-06-27 12:21:56 EDT
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.
Comment 5 Ville Skyttä 2006-06-27 17:10:11 EDT
(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
Comment 6 Paul Wouters 2006-06-27 18:16:19 EDT
As I was already using disttag, this is obviously not enough, or your original
bug entry was not neccessary/wrong.
Comment 7 Ville Skyttä 2006-06-27 18:32:48 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.