Sean Middleditch wrote:
Could someone please explain why the distro version matters in any way shape or form for any packages save the two or three things like 'fedora-release' ?
(clean) Upgradability from packages currently in fedora, before Fedora Core existed.
If you're package is depending on the distro version, and not the actual components in the distro, your package is probably broken.
In general, I agree with you. I can also assure you, there are good reasons for (sometimes) doing it, but I digress...
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.
-- Rex
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.
Bill
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 -
Bill Nottingham -
Rex Dieter