it should be obvious that the ximian package is older and should be replaced (or if it is newer.. than it should be left...). Maybe this is a simplistic example though...
its never enough to think of the simplistic example...the simplistic examples are never the ones that actually bite you in the arse when you implement things.
First...newest doesn't mean squat! There is a reason why Epoch was invented.
Second...you need to think of dependency chains instead of version numbers. What really really matters are the provides and requires of the packages, not to mention the API or whatever defines how the payload in said package interacts with other things. Version numbers are a horrid measure of worthwhileness. And when it comes to things like libraries..you have to be very particular about what package provides what library...and you have to be very aware that how xim builds its provides/requires can be deliberately inconsistent with how the base does it. http://bugzilla.ximian.com/show_bug.cgi?id=44442
What the hell do you do when yer add-on vendor builds their replacement packages using a dependency NOT in the base? its not just a direct bolt on then. Upgrades from the original vendor would not install cleanly in this case because they were built with a different dependency chain in mind. I contend that once you replace vendor A with vendor B's package...then you must prefer upgrades for that package from vendor B...or you risk major dependency issues. In my world view upgrade tools should try to be smart and by default only choose upgrades from the vendor/gpg sig for the package you already have installed....but this idea breaks down for base upgrades where the basic dependency structure you are relying on is massively changed. I don't have a smug, i know best, answer for how to do a sane base upgrade with multiple layers of 3rd party repo installs yet. But as soon as a dream one up I'll make it a point to beat the idea into the head of every package maintainer on this list. In the case of the base upgrade I think the logic runs the other way...you have to prefer the base package, so that dependancies chains will work out.
You can't hold back development of the base release because it breaks pre-existing 3rd party packages....but hopefully a more open development cycle in the future will mean that interested 3rd party packagers will be able to keep their offerings in sync in a very timely manner. In the meantime...if ximian is not going to take advantage of the beta cycle so that you as an avid ximian fan can test their stuff for the upcoming rhl release...yer SOL. You can't hold up a base release because add-ons, no matter how popular, aren't ready to roll forward.
-jef"but more importantly, ximian has the better t-shirt logo"spaleta
On 18 Aug 2003, Jef Spaleta wrote:
Second...you need to think of dependency chains instead of version numbers. What really really matters are the provides and requires of the packages,
Yes, but I don't know enough about RPM to argue this ;) I had heard some of the problems were because ximian changed some package names. (or other 3rd party software has slightly different package names so that RPM doesn't recognize that it's the same thing to upgrade it.)
provides/requires can be deliberately inconsistent with how the base does it. http://bugzilla.ximian.com/show_bug.cgi?id=44442
I discovered this with Debian before and had to remove/re-install half of my system to purge myself of the mess.
What the hell do you do when yer add-on vendor builds their replacement packages using a dependency NOT in the base? its not just a direct bolt on then. Upgrades from the original vendor would not install cleanly in this case because they were built with a different dependency chain in mind. I contend that once you replace vendor A with vendor B's package...then you must prefer upgrades for that package from vendor B...or you risk major dependency issues. In my world view upgrade
I agree with this, but the problem there is that (As far as I know), you can't use red-carpet to upgrade from Rh8 to rh9, etc. (Can you even do this with RHN?)
tools should try to be smart and by default only choose upgrades from the vendor/gpg sig for the package you already have installed....but this idea breaks down for base upgrades where the basic dependency structure you are relying on is massively changed. I don't have a smug,
And ideally, 3rd party packages won't modify these things, except that Ximian mucks about with Gnome.
i know best, answer for how to do a sane base upgrade with multiple layers of 3rd party repo installs yet. But as soon as a dream one up ... dependancies chains will work out.
You can't hold back development of the base release because it breaks pre-existing 3rd party packages....
I certainly wasn't suggesting that. It was more along the lines of: If someone at redhat could spend a relatively short amount of time and ensure that RH9+xd2 upgrades nicely to RH10, it would be nice. If they can't... (and that's what I am hearing from people who obviously know more about it than myself), then... then they can't.
but hopefully a more open development cycle in the future will mean that interested 3rd party packagers will be able to keep their offerings in sync in a very timely manner.
I think that redhat pushing some changes out to the authors will help solve that in the case of smaller individual packages.
In the meantime...if ximian is not going to take advantage of the beta cycle so that you as an avid ximian fan can test their stuff for the upcoming rhl release...yer SOL. You can't hold up a base release because add-ons, no matter how popular, aren't ready to roll forward.
Of course, and I don't think anyone would want them to. A release at least puts pressure on the 3rd parties to make the add-ons work in a hurry. I like Ximian, but I don't know is "avid" would describe my level of worship. If red-carpet would function well for debian testing and Rawhide, then that might happen ;)
-jef"but more importantly, ximian has the better t-shirt logo"spaleta
This is true.. but most importanly, Mr. Cox has chimed on in this thread now, and I can't argue with him! ;)
-- noah silva
p.s.: My expertise is in Debian, Solaris, and AIX.. this Redhat stuff I have only been playing with since v8.0, so I may occasionally say something very silly.