Re: [SLE] KDE3.1-Beta2 Please, SuSE, Don't do it like that.
Installing the 3.1 beta right over my 3.0 was really mean. My system is just coming back to normal. I didn't expect that. I really thought SuSE had outgrown little foibles like this one. I love SuSE Linux. When I buy the box, I know I'm getting the best OS in the world. I've bought at least one, often two boxes of every release since 5.2. I'll be picking up 8.1 on Monday.
I simply can't imagine that SuSE would ship such a wonderful product and then put out these beta rpms on the net to mess it up. I know it's October Fest time in Bavaria, but sheez!
STH First off - SuSE doesn't release the packages on the kde.org site. While a
On Saturday 05 October 2002 05:45 pm, Steven T. Hatton wrote: person responsible for some SuSE packages in the actual system may be the one doing the KDE.org packages, it isn't SuSE. Secondly, it isn't difficult to find out where packages will be installed or what will happen when you install packages, prior to actually doing so. And finally, these are beta upgrade packages. they are to test what will happen when the final release comes out. It is important that you see how well they upgrade the existing environment. If they were simply installed next to the other packages and when finally released they broke the upgrade, you would be complaining 10 times worse. You install a Beta you know what a beta is. If you want to test without it overwriting your existing environment, relocate the RPMs.
On Sunday 06 October 2002 00.45, Anthony Moulen wrote:
And finally, these are beta upgrade packages.
WTF is an upgrade package?
they are to test what will happen when the final release comes out. It is important that you see how well they upgrade the existing environment.
What?
If they were simply installed next to the other packages and when finally released they broke the upgrade, you would be complaining 10 times worse.
What are you on about? All binaries/scripts/whatever in /opt/kde3 from 3.0.3 disappear, and get replaced by 3.1. There's absolutely no "upgrade" going on there. You may be confusing things with YOU's patch rpms. These are not patch rpms. The only upgrade here is to the things in $HOME/.kde and you can test that without blowing away the kde 3.0.3 installation. I did, when I installed from CVS. And so did every previous beta.
You install a Beta you know what a beta is. If you want to test without it overwriting your existing environment, relocate the RPMs.
The obvious point is this: no previous beta has overwritten the "stable" version. None at all. If they suddenly change policy, people will get rudely surprised. And for no reason whatever. //Anders
On Saturday 05 October 2002 06:54 pm, Anders Johansson wrote:
On Sunday 06 October 2002 00.45, Anthony Moulen wrote:
And finally, these are beta upgrade packages.
WTF is an upgrade package?
What do you call an RPM that upgrades another RPM? Seems like upgrade package makes a lot of sense to me. It isn't a patch because it is from a different minor vesion. Patches are only for changes to patch levels (3.0.1 to 3.0.2 to 3.0.3).
If they were simply installed next to the other packages and when finally released they broke the upgrade, you would be complaining 10 times worse.
What are you on about? All binaries/scripts/whatever in /opt/kde3 from 3.0.3 disappear, and get replaced by 3.1. There's absolutely no "upgrade" going on there. You may be confusing things with YOU's patch rpms. These are not patch rpms.
Tell me that if a final upgrade between 3.0.3 to 3.1 comes along that you wouldn't have a fit if the upgrade broke something? Who is going to test these packages if not beta testers? Who is going to protect the end users from a bad upgrade?
The only upgrade here is to the things in $HOME/.kde and you can test that without blowing away the kde 3.0.3 installation. I did, when I installed from CVS. And so did every previous beta.
What do you use to login? I assume you login via KDM. Have you ever tried to upgrade KDM and have it mess up? This is an important thing for people who will later upgrade their "production" environments. Do you know what will happen to your third party or extra kde packages? Like KVIRC or other KDE packages that were installed in /opt/kde3? This is important to people with production environments. If you just want to play with kde3.1 download the source and install it anywhere you want. But someone has to test what will happen when you upgrade the main components of KDE.
You install a Beta you know what a beta is. If you want to test without it overwriting your existing environment, relocate the RPMs.
The obvious point is this: no previous beta has overwritten the "stable" version. None at all. If they suddenly change policy, people will get rudely surprised. And for no reason whatever.
Are you absolutely positive on this? Back in the kde2 days I installed a beta package between kde2 releases that overwrote my stable kde2 packages. It majorly broke KDM and required manual tweaking. When the final upgrade came out between kde2 versions, it worked perfectly. Probably because some beta users reported it back to the packagers, who modified their scripts. I keep a machine that I run betas of major packages on, like kde, sometimes kernels, Xfree and the like.
On Sunday 06 October 2002 02.06, Anthony Moulen wrote:
On Saturday 05 October 2002 06:54 pm, Anders Johansson wrote:
On Sunday 06 October 2002 00.45, Anthony Moulen wrote:
And finally, these are beta upgrade packages.
WTF is an upgrade package?
What do you call an RPM that upgrades another RPM? Seems like upgrade package makes a lot of sense to me.
And exactly how does it differ from a plain regular rpm?
It isn't a patch because it is from a different minor vesion. Patches are only for changes to patch levels (3.0.1 to 3.0.2 to 3.0.3).
Not really. A patch rpm is a SuSE thing that only contains the differences between the installed version and the new one.
If they were simply installed next to the other packages and when finally released they broke the upgrade, you would be complaining 10 times worse.
What are you on about? All binaries/scripts/whatever in /opt/kde3 from 3.0.3 disappear, and get replaced by 3.1. There's absolutely no "upgrade" going on there. You may be confusing things with YOU's patch rpms. These are not patch rpms.
Tell me that if a final upgrade between 3.0.3 to 3.1 comes along that you wouldn't have a fit if the upgrade broke something? Who is going to test these packages if not beta testers? Who is going to protect the end users from a bad upgrade?
You can test this perfectly well without wiping the 3.0.3 installation.
The only upgrade here is to the things in $HOME/.kde and you can test that without blowing away the kde 3.0.3 installation. I did, when I installed from CVS. And so did every previous beta.
What do you use to login? I assume you login via KDM. Have you ever tried to upgrade KDM and have it mess up? This is an important thing for people who will later upgrade their "production" environments.
Yes, but you can test it without wiping the 3.0.3 installation.
Do you know what will happen to your third party or extra kde packages?
Yes. If they're not recompiled against kde 3.1 they will fail. It is irrelevant to this discussion. //Anders
On Sunday 06 October 2002 07:24 am, Anders Johansson wrote:
On Sunday 06 October 2002 02.06, Anthony Moulen wrote:
Tell me that if a final upgrade between 3.0.3 to 3.1 comes along that you wouldn't have a fit if the upgrade broke something? Who is going to test these packages if not beta testers? Who is going to protect the end users from a bad upgrade?
You can test this perfectly well without wiping the 3.0.3 installation.
I'm not so sure of that. It's almost impossible to create 100% reliable 'test cases'. You really don't know what will happen until you do things the way they will be done in production.
What do you use to login? I assume you login via KDM. Have you ever tried to upgrade KDM and have it mess up? This is an important thing for people who will later upgrade their "production" environments.
Yes, but you can test it without wiping the 3.0.3 installation.
Do you know what will happen to your third party or extra kde packages?
Yes. If they're not recompiled against kde 3.1 they will fail. It is irrelevant to this discussion.
Well, that isn't necessarily true. If someone comes up with a compatability package which keeps the old libs around in the new version, that can keep your old stuff alive. Quite often you don't know you've broken something until you actually try to run it and find out, @#^, I need the old abc.so.5 for this! I really didn't want to jump on anybody for the way this worked out. I'm not interested in blame. That would only discourage people. I want improvement. And I understand that we all have to cut corners here and there. Perhaps that README I wanted is one of the corners that got cut. When in doubt, read the warranty. When you play with fire, you can expect that you may end up without eyebrows from time to time. That's life.
//Anders
On Sunday 06 October 2002 17.30, Steven T. Hatton wrote:
I'm not so sure of that. It's almost impossible to create 100% reliable 'test cases'. You really don't know what will happen until you do things the way they will be done in production.
In this case that's not true. An "upgrade" using rpm is the same as the uninstall of the previous version followed by an install of the new. That's why you sometimes get messages like "Can't remove foo/ - directory not empty". That is the old package being "rpm -e":ed. So as far as functionality is concerned, there's absolutely no difference between putting the new beta in, say, /opt/kde3.1-beta or putting it in /opt/kde3 as a straight "upgrade". Except that in the former case you have a working installation to fall back on if the beta doesn't work.
Well, that isn't necessarily true. If someone comes up with a compatability package which keeps the old libs around in the new version, that can keep your old stuff alive. Quite often you don't know you've broken something until you actually try to run it and find out, @#^, I need the old abc.so.5 for this!
As I said, it's irrelevant to this discussion. If you allowed for that you might as well say you can run kde2 programs under kde3. You can't, but suse has a compat package that lets you do it, but that is irrelevant to the main issue. Besides, and this is a comment I wanted to make in the first place but forgot, we're supposed to be beta testing kde here, not spec files. Sure it's interesting to see if suse's rpms will work when it comes time to take the plunge, but it's not beta testing kde, it's beta testing suse's spec files. //Anders
On Saturday 05 October 2002 06:45 pm, Anthony Moulen wrote:
On Saturday 05 October 2002 05:45 pm, Steven T. Hatton wrote:
Installing the 3.1 beta right over my 3.0 was really mean. My system is just coming back to normal. I didn't expect that. I really thought SuSE had outgrown little foibles like this one. I love SuSE Linux. When I buy the box, I know I'm getting the best OS in the world. I've bought at least one, often two boxes of every release since 5.2. I'll be picking up 8.1 on Monday.
I simply can't imagine that SuSE would ship such a wonderful product and then put out these beta rpms on the net to mess it up. I know it's October Fest time in Bavaria, but sheez!
STH
First off - SuSE doesn't release the packages on the kde.org site. While a person responsible for some SuSE packages in the actual system may be the one doing the KDE.org packages, it isn't SuSE.
That's good to know. It should probably be made more clear on the KDE site. As you see, some of us drew the conclustion that SuSE were responsible for creating the packages.
Secondly, it isn't difficult to find out where packages will be installed or what will happen when you install packages, prior to actually doing so.
I shold have looked. I was just doing what I did last time. A README might be helpful. It wouldn't have to say much. Just, "the default will install into your existing KDE directory. The packages are relocatable. Here's how to install them some place else.... This set of RPMS was provided by ..."
And finally, these are beta upgrade packages. they are to test what will happen when the final release comes out. It is important that you see how well they upgrade the existing environment.
This does make sense. Again, a bit of a warning might be helpful.
If they were simply installed next to the other packages and when finally released they broke the upgrade, you would be complaining 10 times worse. You install a Beta you know what a beta is. If you want to test without it overwriting your existing environment, relocate the RPMs.
You better believe I'll look before I pull the trigger next time. I really appreciate your efforts in providing these. I wish I know more about pulling this stuff together. I attempted doing this with the XEmacs beta stuff, but I didn't get it to work. STH
participants (3)
-
Anders Johansson -
Anthony Moulen -
Steven T. Hatton