Severn Beta2

[Jef Spaleta]

>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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/test/attachments/20030818/4879aa94/attachment.bin