Severn Beta2

[Noah Silva [Mailing list]]

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.