On Tue, Sep 30, 2003 at 03:09:35PM -0400, Bill Nottingham wrote:
Rex Dieter (rdieter(a)math.unl.edu) said:
> If you read the original post, Axel's concern to upgradability from the
> previous fedora release naming standard. A concern of mine is that I
> maintain packages for all redhat releases going back to rh73, and I do it
> all from a single src.rpm, and dynamically generate a Release tag based
> upon the contents of /etc/redhat-release. Like Axel, I also would like to
> maintain upgradability from previous releases. I argue that having to
> increment Epoch solely for the purpose overcoming the Release drop (9 ->
> 0.9 ) to maintain upgrade paths is yucky.
Well, it would have to change anyway, from rh73 to fXXX, so, you'll
still need a change of some sort.
Seriously, changing the release version notes the change in
the release itself; its goals, its features, its methodology.
So the current goals and methology are to intentionally break heritage
and upgradability from rh <= 9? What happened to the goal of the new
project to better support external developers and packagers? Currently
I only see more problems as an external packager.
It is a pity to see marketing issues and company politics creating
Couldn't you find a technical clean way to promote FC's goals? Call
the core "Fedora Core sponsored by Red Hat version 10" and let the tag
"rh10" do its packaging wonders.
Or come up with a viable solution for repos supporting multiple RH
releases with the follwoing constraints:
o Allow upgradability like
... <= rh7.3 <= rh8.0 <= rh9 <= "fc1" <= ...
o No epoch inflation
o No separate specfile maintenance.
You'll probably need the latter design for Fedora Legacy anyway, so
don't let the problem manifest in the next release. You can still fix
it, if you want to.