yum – … how Suse screwed it up

Today is the day where an old article from me about Setting up yum on SUSE LINUX 10.0 gots it 10.000th click – that’s quite a lot, and is only covered by the KDE 3.5 alpha screenshot show I did months ago.

And although I stopped using Suse and do not update these information in the yum lists anymore, I still get some feedback about this article from time to time – including people asking me on jabber or asking me on discussion pages of the susewiki which I left months ago with a note of not comming back so fast also.

It gave me one final impression: There was a big interest in using yum on Suse. So the people were not satisfied with the solutions given comming with Suse.
So Novell/Suse screwed it up!

They actually screwed the whole package management stuff around Suse up – completely. It is a mess. They tried to include everthing out of no understandable reason, and failed in all cases. And even when I offered help and filled bug reports against the stuff and tried to actual solve the problems or point them to the needed solutions, they did not react – in fact, they did not even move, although they pretended on IRC or in the bug reports that they will do.

But to give you a better idea, a short overview about what has happened:

After Suse announced that Suse will be developed in a open project called openSuse the excitement was pretty high. I was also attracted and switched over to the new, final openSuse. One of the reasons for me were that I hoped to get easy working graphics drivers and a easy going configuration base system (yast) together with things which are familiar to me: Suse, which was already running on rpm base, had announced that it would support alternative package managing systems also, yum seemed to be reachable for me on Suse systems.
Btw.: They also claimed they would support apt for rpm officially, which I thought was a little bit odd because form my point of view apt for rpm is inferior to yum. Besides, the development of apt for rpm was already dead and was dropped even by the main developer in favour of another, new system.
Anyway: Soon it turned out that the only thing where yum was supported where that yum was delivered as package and that the main software source for Suse 10.0 had yum metadata information – that was it. Other interesting Suse sources had no yum metadata and hence couldn’t be used by suse yum users, not to mention the update sources which were not supporting yum also – so even if you were interested to install yum by yourself, you were not able to keep your system up2date.
Do I have to mention, that one of the biggest powers and biggest advantages of yum, server side mirror lists, where not supported at all?

And the situation was this: When Suse 10.0 was launched, someone had released the launch information a bit to early, and the release and the main Servers broke down due to have load. Because yast, the standard software management system of Suse, was not able to work with mirror lists, all people trying to use yast made the situation even worth.
It was the same about the apt4rpm users because apt is supporting mirrors lists just as little as yast.

Their would have been the chance for a big breakthrough of yum on the Suse side: they could have launched a the mirrorlists at least for the yum users and point this possibility out on the mail lists and everywhere else, to get rid of a little bit of load balance. The main advantage of these mirror lists is that first the distributor can chose who is on that list, and that second yum picks the servers from that list by itself by luck, so the load is equal balanced on the different servers. All you need for that is one running server which provides some text files – something even I was able to do.

But no – Suse did not see the chance, and Suse did not use this chance to introduce a nice and comfortable package management tool which is also used by other rpm distributions, and, btw., is in a very healthy development and can be extended by plugins…
Instead of using this opportunity Suse just waited until the load on the servers dropped, and believed in the power of talking to people to edit their yast configuration to add mirrors manually, and let enough time pass by to let the people get the impression that package management on Suse just does nothing but sucks – what a tremendous strategy!

Fedora Core had the same problem with heavy load balances with its first releases, and yum was finally able to solve this problem – let’s wait if Fedora Core 5 will face the same problems as Suse 10.0 when it is released – I bet not, because they’ve learned from their mistakes in the past already, and Fedora Core 4 was released without any bigger problems. Suse does not use the opportunity to learn from mistakes others did, I think, but has to make the same mistakes as well and – it looks to me – sometimes without learning…

Because today they try to go their own way again – this time with a package manager from Ximian, integrated into yast. I have no idea why they did this, probably because they own Ximian and want to be nice to the guys, and probably because the Ximian system is quite nice – I never had the chance to work with it.
But even if it has some advatanges, there must be some silly things in this solution: The beta counter for Suse 10.1 has already reached 5, together with the big warning message that due to problems with the new package manager these versions should ONLY be tested and installed by very experienced users. Does not sound like a beta version, am I right?

I do not know what they are doing, or what the big problem is, but they have serious problems, and they are not able to solve them easily – a lot of these problems are introduced by themselves so far, because they haven’t had these problems when they just used yast for everything and ignored all the other solutions. Looks like beeing not the perfect idea, but not beeing the worst, because this is happening at the moment.

Butok, even if they are going to find their way and will finally implement the new system, there is one thing I would like to ask Suse or Novell for: drop these package managers you do not support instead of trying to act like you would support them soon. That’s not only stupid, that’s ridiculous.
Drop what you do not need – apt4rpm is dead, so drop it, for the sake of clarity! And drop yum if you do not want to support it – do not answer in ridiculous ways that you will add mirror lists and supporting update repositories soon, but just say you will never do it and will drop yum from Suse again.
Or, the other way around: do it like you pretend to do it with KDE and Gnome: support them real! If you say you are supporting yum – then do it. But do it right!

I must say: I was very excited about the whole “openSuse will be community development” thing – but until now they screwed me up then they done right, and if they continue to go along this road, they will Screw up even more, and will throw away more and more opportunities to get some stuff seriously running.

Nevertheless: we are free to do what ever we want to do as long as we are using Free Software, and so I did what I wanted to do: I used Suse with uym as good as possible, and finally, I took the freedom to leave Suse behind me and to come back to Fedora Core. Looks like I will stay here for a longer time again😉

4 thoughts on “yum – … how Suse screwed it up”

  1. Have you read SuSE’s note on 10.1? The new package manager will support yum as well as tradicional Yast repositories and Ximian’s

  2. Sure do I know this – and as I wrote, just check the beta release information, that’s nothing which is in beta state.

    But even if the finally get it working nice, that’s not the point. The problem is that Suse didn’t think about before the acted, and weren’t listening or thinking after the have acted.

    Besides, it’s nice if the new package manager can use yum repositories, but the interesting question if it is capable of similar features: auto mirror-choosing on the fly, plugable backend, capable of dealing with the x86/64 issue apt suffers from, arch-independent source lines which can be easily shared among users of different architectures, etc.
    We will see.

    Until we know there is just the fact that Suse messed the whole package management up – whatfor else are so many people still interested in the yum article? And, btw., this is not the only source, the article is copied and translated in different languages and can be found on several web pages.

    liquidat

  3. As far as I know the new package manager is build upon the old red carpet manager, so it is not smart, I think.

    We will see when Suse Linux 10.1is released – until then I do not have the time to test the beta versions:-/

    liquidat

Comments are closed.