On Fri, 5 Jan 2007 08:43:43 +0100, Axel Thimm wrote:
> Hi,
>
> it has often come up lately that since the "Core" will be removed from
> Fedora as a name the currently used disttag of fcN needs to be
> adjusted. As long as people were discussing what Fedora will be named
> it was difficult to nail some acronym, but now the simple "Fedora"
> emerged (which is good IMO).
>
> The problem is that the natural disttag of f7 is rpm-lesser that any
> fcN. There are two paths to take:
>
> a) Don't care about upgrade paths through disttags, just rebuild
> everything with a higher buildid (the part of the release before
> the disttag) and you can pick any disttag you like.
>
> The pros are obviously that one can use .f7, the cons are that
> we'll artificially introduce a specfile difference between many
> fc5/fc6 and f7/f8 specfiles which will make maintenance more error
> prone (foo will be foo-1-1.fc5, foo-1-1.fc6, foo-1-2.f7,
> foo-1-2.f8, e.g. foo-1-1%{?dist} pre- and foo-1-2%{?dist}
> post-merge). Add RHEL4/5 to the mix and the buildid confusion is
> perfect. It would haunt us until early 2008 (EOL for fc6), but then
> we'd be using our favourite disttag w/o a specfile era barrier
> anymore.
The bottom part of that "a)" point enters too much wrong information into
spec changelogs already. Just watch commits-list a bit to see how history
is changed when spec files are copied over from newer branches. Sometimes
changelog entries disappear. And not seldomly, mass-updates to multiple
branches of the distribution are untested and break something. The top
part of "a)" is misguidance. Using dist tags does not ensure sane upgrade
paths in all known scenarios. Only in conjunction with full *online*
upgrades, dist tags simplify package versioning.
Hence:
a.2) Do care about upgrade paths _without_ using dist tags. Start using
stricter versioning with Epoch bumps as necessary, possibly even a hidden
Dist Epoch inside RPM. Core+Extras merge. Packages from (ex-)Extras find
their way into a collection and into the ISO images (snapshots!). We have
arrived at the point where all package EVR tuples for the previous
distribution versions (including upgrade and errata packages) ought to
lose RPM version comparison when compared with any of the package EVRs for
the newer distributions. This is especially useful when somebody upgrades
from an up-to-date Fedora N-1 to the CD/DVD release of Fedora N.
If we continue upgrading packages in the merged "Fedora" distribution as
has been done in Fedora Extras before (ABI breakage, renames, and other
things), there will be many burnt fingers during firstboot, and prior to a
first full online update in general.
--
Fedora-maintainers mailing list
Fedora-maintainers@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-maintainers
--
Fedora-maintainers-readonly mailing list
Fedora-maintainers-readonly@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
