On Tue, Sep 30, 2003 at 03:09:35PM -0400, Bill Nottingham wrote: > Rex Dieter (rdieter 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 these problems. 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. -- Axel Thimm physik fu-berlin de
Attachment:
pgp00000.pgp
Description: PGP signature