On Tuesday 26 June 2007 10:48:57 Jeroen van Meeuwen wrote:
I'm sure I'm saying something stupid, but isn't an
upgrade path like that
1) "unlikely" to happen while packages get updated every now and then,
and thus will have a complete upgrade path at some point, while
1.2-1.fc7 is installed on a machine that gets update 1.2-2.f8
The same version-release gets applied across the branches fairly often. This
is not a made up scenario.
2) not used by anaconda upgrade -i'm not sure about this one ;-)
We're talking about enabling anaconda upgrades to make use of external repos
at upgrade time, in which case this very much /would/ be used by anaconda
upgrade.
3) used only by the not-recommended yum upgrade -again, the
"only" part
I'm not sure about
While not upgraded, it is something we try hard to make at least possible.
Part of that is ensuring we don't break upgrade paths.
4) completely unnecessary while both .fc7 and f8 programs have the
same
version number, source and are built with the same spec
Not so. Each branch could have different tool sets (gcc), different rpm
version creating the package, etc.. Or in the case of python you could be
seeing a completely different location on the file system (python2.4 vs
python2.5)
5) easily fixed by bumping the release number for the
'later' package
Why needlessly "fork" the spec file when the majority of the value of dist
tags lies in being able to use the identical spec across the branches?
6) happening regularly with like dev/udev, libata, stuff like that?
How is this happening regularly? We're very against breaking upgrade paths in
RPM NVRs. rel-eng just passed a vote that requires rpm nvr paths to be
upgradeable at any stage of Fedora development.
I'm sure I'm missing something that prevents 'f8'
being the dist-tag,
I'm no release engineer after all. These are just things that come to my
mind.
--
Jesse Keating
Release Engineer: Fedora