HI! Is it already known, if I will be able to update a 10.1 RC1 installation to 10.1 final (when available) by simply updating all changed RPMs? Thanks! Thomas
Hi, Also can you go from 10.1 RC1 to 10.1 final by just doing and online update using YAST? Thanks Rene Thomas Börkel wrote:
HI!
Is it already known, if I will be able to update a 10.1 RC1 installation to 10.1 final (when available) by simply updating all changed RPMs?
Thanks!
Thomas
--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-help@opensuse.org
If you can find the RPM repository, you could just create a yum repository file in /etc/yum.repos/suse-base to a install source (a url that contains the repodata folder) For example: [suse-base] name=suse-base baseurl=http://ftp.opensuse.org/pub/opensuse/distribution/SL-OSS-factory/inst-source... enabled=1 gpgcheck=0 Then, run yum update That should at least upgrade all of your packges to the version of the next distro. I've upgraded many a times fedora core from an entire number to the next via yum, I don't see any reason why you couldn't do it with SUSE. Tim On Thursday 13 April 2006 08:30, Rene Salmon wrote:
Hi,
Also can you go from 10.1 RC1 to 10.1 final by just doing and online update using YAST?
Thanks Rene
Thomas Börkel wrote:
HI!
Is it already known, if I will be able to update a 10.1 RC1 installation to 10.1 final (when available) by simply updating all changed RPMs?
Thanks!
Thomas
--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-help@opensuse.org
--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-help@opensuse.org
On Thu, 13 Apr 2006, Tim Harper wrote:
If you can find the RPM repository, you could just create a yum repository file in /etc/yum.repos/suse-base to a install source (a url that contains the repodata folder)
For example:
[suse-base] name=suse-base baseurl=http://ftp.opensuse.org/pub/opensuse/distribution/SL-OSS-factory/inst-source... enabled=1 gpgcheck=0
Why oh *why* would you disable gpgcheck?
Then, run yum update
That should at least upgrade all of your packges to the version of the next distro. I've upgraded many a times fedora core from an entire number to the next via yum, I don't see any reason why you couldn't do it with SUSE.
One very good reason is that sometimes the version (and package) number
of a package between betas (or rc's) and final may not change but the
actual content may.
What I mean is this: let's say you have a package 'foo' version 1.0,
release 1. The RPM would then be: foo-1.0-1
Let's say that the compiler changes between releases, and the foo
oackage gets rebuilt. Now, foo's source and packaging didn't change, so
the version and release number don't change either. However, the
contents did change.
--
Carpe diem - Seize the day.
Carp in denim - There's a fish in my pants!
Jon Nelson
On Thursday 13 April 2006 15:30, Jon Nelson wrote:
Why oh *why* would you disable gpgcheck?
Because I don't know where to get the gpg key, and I don't want to take the time to figure that out right now :P Want to shed some enlightenment on the subject?
On Thursday 13 April 2006 15:30, Jon Nelson wrote:
One very good reason is that sometimes the version (and package) number of a package between betas (or rc's) and final may not change but the actual content may.
What I mean is this: let's say you have a package 'foo' version 1.0, release 1. The RPM would then be: foo-1.0-1
Let's say that the compiler changes between releases, and the foo oackage gets rebuilt. Now, foo's source and packaging didn't change, so the version and release number don't change either. However, the contents did change. So what your saying is, as long as suse doesn't change compilers from version 10.1-rc1 to 10.1-final, then this will work fine?
Tim
On Thursday 13 April 2006 15:30, Jon Nelson wrote:
Let's say that the compiler changes between releases, and the foo oackage gets rebuilt. Now, foo's source and packaging didn't change, so the version and release number don't change either. However, the contents did change. Also, why would that make a difference at all, if the compiler changed? I could see why it would make a difference if the compiler was producing bad code, but other than that, what effect would that have?
Curious Tim
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jon Nelson wrote:
On Thu, 13 Apr 2006, Tim Harper wrote: ...
That should at least upgrade all of your packges to the version of the next distro. I've upgraded many a times fedora core from an entire number to the next via yum, I don't see any reason why you couldn't do it with SUSE.
One very good reason is that sometimes the version (and package) number of a package between betas (or rc's) and final may not change but the actual content may.
What I mean is this: let's say you have a package 'foo' version 1.0, release 1. The RPM would then be: foo-1.0-1
Let's say that the compiler changes between releases, and the foo oackage gets rebuilt. Now, foo's source and packaging didn't change, so the version and release number don't change either. However, the contents did change.
In theory, you are absolutely correct. But in this case that won't
happen, as SUSE uses an automated build process that counts up the
release as soon as a new build happens (AFAICR - correct me if I'm wrong).
And I'd use smart over yum any time ;)
cheers
- --
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\
On Thu, 13 Apr 2006, Pascal Bleser wrote:
Let's say that the compiler changes between releases, and the foo oackage gets rebuilt. Now, foo's source and packaging didn't change, so the version and release number don't change either. However, the contents did change.
In theory, you are absolutely correct. But in this case that won't happen, as SUSE uses an automated build process that counts up the release as soon as a new build happens (AFAICR - correct me if I'm wrong).
No, we don't raise the release number with every rebuild at the moment. Regards Christoph
On Fri, Apr 14, 2006 at 11:46:18AM +0200, Christoph Thiel wrote:
No, we don't raise the release number with every rebuild at the moment.
So, now is your chance to explain why this is the case. This was mentioned already once before only with the reason that there were some problems when you did. I'd be interested in what sort of problems there are if you increase on each rebuild. Robert -- Robert Schiele Tel.: +49-621-181-2214 Dipl.-Wirtsch.informatiker mailto:rschiele@uni-mannheim.de "Quidquid latine dictum sit, altum sonatur."
On Fri, Apr 14, 2006 at 03:28:04PM +0200, Robert Schiele wrote:
On Fri, Apr 14, 2006 at 11:46:18AM +0200, Christoph Thiel wrote:
No, we don't raise the release number with every rebuild at the moment.
So, now is your chance to explain why this is the case. This was mentioned already once before only with the reason that there were some problems when you did. I'd be interested in what sort of problems there are if you increase on each rebuild.
Still waiting for an answer to this question. Anyone with a clue here? Robert -- Robert Schiele Tel.: +49-621-181-2214 Dipl.-Wirtsch.informatiker mailto:rschiele@uni-mannheim.de "Quidquid latine dictum sit, altum sonatur."
On Mon, Aug 14, 2006 at 08:05:06PM +0200, Robert Schiele wrote:
On Fri, Apr 14, 2006 at 03:28:04PM +0200, Robert Schiele wrote:
On Fri, Apr 14, 2006 at 11:46:18AM +0200, Christoph Thiel wrote:
No, we don't raise the release number with every rebuild at the moment.
So, now is your chance to explain why this is the case. This was mentioned already once before only with the reason that there were some problems when you did. I'd be interested in what sort of problems there are if you increase on each rebuild.
Still waiting for an answer to this question. Anyone with a clue here?
Ok, sice nobody could answer this for more than 5 months now it seems that there is nobody here that has a clue about this bug. Just wanted to inform you that YaST cannot handle this situation correctly and decides on update to delete all affected packages ignoring dependencies even when the affected packages are part of the vital base system like perl. Expect that ignoring this problem will get back at you at a later point in time but since you get either no or just a stupid answer when talking about this to someone I will now just sit down and wait for the disaster... Robert -- Robert Schiele Dipl.-Wirtsch.informatiker mailto:rschiele@gmail.com "Quidquid latine dictum sit, altum sonatur."
Robert Schiele
Ok, sice nobody could answer this for more than 5 months now it seems that there is nobody here that has a clue about this bug.
Sorry, if this got lost.
Just wanted to inform you that YaST cannot handle this situation correctly and decides on update to delete all affected packages ignoring dependencies even when the affected packages are part of the vital base system like perl. Expect that ignoring this problem will get back at you at a later point in time but since you get either no or just a stupid answer when talking about this to someone I will now just sit down and wait for the disaster...
We increment it now whenever we do a checkin of the basesystem. Would this still cause problems? Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
On Mon, Oct 02, 2006 at 09:30:30AM +0200, Andreas Jaeger wrote:
Robert Schiele
writes: Ok, sice nobody could answer this for more than 5 months now it seems that there is nobody here that has a clue about this bug.
Sorry, if this got lost.
Just wanted to inform you that YaST cannot handle this situation correctly and decides on update to delete all affected packages ignoring dependencies even when the affected packages are part of the vital base system like perl. Expect that ignoring this problem will get back at you at a later point in time but since you get either no or just a stupid answer when talking about this to someone I will now just sit down and wait for the disaster...
We increment it now whenever we do a checkin of the basesystem. Would this still cause problems?
No, you don't. You updated the db package (which is definitely part of the base system) to 4.4 release but did _not_ increase the number thus causing YaST to decide to destroy the installed system on upgrade. But I repeat the question: Is there a _serious_ reason at all for not updating the release number when the package is rebuilt? Robert -- Robert Schiele Dipl.-Wirtsch.informatiker mailto:rschiele@gmail.com "Quidquid latine dictum sit, altum sonatur."
Robert Schiele
On Mon, Oct 02, 2006 at 09:30:30AM +0200, Andreas Jaeger wrote:
Robert Schiele
writes: Ok, sice nobody could answer this for more than 5 months now it seems that there is nobody here that has a clue about this bug.
Sorry, if this got lost.
Just wanted to inform you that YaST cannot handle this situation correctly and decides on update to delete all affected packages ignoring dependencies even when the affected packages are part of the vital base system like perl. Expect that ignoring this problem will get back at you at a later point in time but since you get either no or just a stupid answer when talking about this to someone I will now just sit down and wait for the disaster...
We increment it now whenever we do a checkin of the basesystem. Would this still cause problems?
No, you don't. You updated the db package (which is definitely part of the
That's a bug ;-(
base system) to 4.4 release but did _not_ increase the number thus causing YaST to decide to destroy the installed system on upgrade.
But I repeat the question: Is there a _serious_ reason at all for not updating the release number when the package is rebuilt?
We rebuild that often that people often asked: What's the difference between version -9 and -20? And we have to answer: Just rebuild with newer packages. It would be great to only increase the number if a dependend package changes the ABI. So, neither solution is really good. Could you file a bugreport against basesystem, please? I'll take care of it and discuss with Rudi once he's back from vacation how to finally solve this. Thanks, Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
On Mon, Oct 02, 2006 at 10:14:22AM +0200, Andreas Jaeger wrote:
Robert Schiele
writes: No, you don't. You updated the db package (which is definitely part of the
That's a bug ;-(
This is what I am saying for years now but received only really stupid answers in response to that like: "We don't consider this a problem for us internally".
We rebuild that often that people often asked: What's the difference between version -9 and -20? And we have to answer: Just rebuild with newer packages. It would be great to only increase the number if a
So what you are basically saying is that you fear that some people ask quetions and prefer incorrectness of the system over just answering these questions? Didn't expect you to be that reclusive.
dependend package changes the ABI.
Well, until you did implement that just expect _every_ rebuild to result in an ABI change. If you expected the ABI not to change you wouldn't need to rebuild.
So, neither solution is really good.
Huh? What is the real _problem_ with just telling the truth that the package number increased due to a dependency rebuild?
Could you file a bugreport against basesystem, please? I'll take care of it and discuss with Rudi once he's back from vacation how to finally solve this.
Ok, did so now. Is there also a chance that this discussion will not again take place completely behind the curtain without getting any resons for the final decision. Robert -- Robert Schiele Dipl.-Wirtsch.informatiker mailto:rschiele@gmail.com "Quidquid latine dictum sit, altum sonatur."
Robert Schiele
On Mon, Oct 02, 2006 at 10:14:22AM +0200, Andreas Jaeger wrote:
Robert Schiele
writes: No, you don't. You updated the db package (which is definitely part of the
That's a bug ;-(
This is what I am saying for years now but received only really stupid answers in response to that like: "We don't consider this a problem for us internally".
We rebuild that often that people often asked: What's the difference between version -9 and -20? And we have to answer: Just rebuild with newer packages. It would be great to only increase the number if a
So what you are basically saying is that you fear that some people ask quetions and prefer incorrectness of the system over just answering these questions? Didn't expect you to be that reclusive.
I was a bit short: The problem is especially with release products. Your release today -9 and in a month -20 - with just one change. This confused a lot of customers and partners, they asked for the other 10 changes...
dependend package changes the ABI.
Well, until you did implement that just expect _every_ rebuild to result in an ABI change. If you expected the ABI not to change you wouldn't need to rebuild.
So, neither solution is really good.
Huh? What is the real _problem_ with just telling the truth that the package number increased due to a dependency rebuild?
People just not getting it. :-(. Trust me, this is a real problem. But it might be different for FACTORY and released products...
Could you file a bugreport against basesystem, please? I'll take care of it and discuss with Rudi once he's back from vacation how to finally solve this.
Ok, did so now. Is there also a chance that this discussion will not again take place completely behind the curtain without getting any resons for the final decision.
Let's try it ;-) Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
On Mon, Oct 02, 2006 at 12:29:40PM +0200, Andreas Jaeger wrote:
I was a bit short: The problem is especially with release products. Your release today -9 and in a month -20 - with just one change. This confused a lot of customers and partners, they asked for the other 10 changes...
You must have really stupid customers and partners. Accept my deep sympathy for this.
Huh? What is the real _problem_ with just telling the truth that the package number increased due to a dependency rebuild?
People just not getting it. :-(. Trust me, this is a real problem.
So development decission are typically driven by people that have no clue? Interesting... Honestly, if I have to decide in a project I tend to run away from vendors that do the wrong thing just because some stupid people ask them to do so. But I agree with you that if you have more stupid customers than intelligent ones it might be smarter to serve the stupid ones. I still wonder where all these stupid people come from. If I explain dependency resolution algorithms to our freshman students most of them get it. Robert -- Robert Schiele Dipl.-Wirtsch.informatiker mailto:rschiele@gmail.com "Quidquid latine dictum sit, altum sonatur."
On Mon, 2006-10-02 at 12:29 +0200, Andreas Jaeger wrote:
Robert Schiele
writes: On Mon, Oct 02, 2006 at 10:14:22AM +0200, Andreas Jaeger wrote:
Robert Schiele
writes: No, you don't. You updated the db package (which is definitely part of the
That's a bug ;-(
This is what I am saying for years now but received only really stupid answers in response to that like: "We don't consider this a problem for us internally".
We rebuild that often that people often asked: What's the difference between version -9 and -20? And we have to answer: Just rebuild with newer packages. It would be great to only increase the number if a
So what you are basically saying is that you fear that some people ask quetions and prefer incorrectness of the system over just answering these questions? Didn't expect you to be that reclusive.
I was a bit short: The problem is especially with release products. Your release today -9 and in a month -20 - with just one change. This confused a lot of customers and partners, they asked for the other 10 changes...
Not bumping the rev would be fine if no source and no deps changed, but
the problem is that deps of the RPM will change right now and the rev
will not be bumped, which seems incorrect.
-JP
--
JP Rosevear
JP Rosevear
Not bumping the rev would be fine if no source and no deps changed, but the problem is that deps of the RPM will change right now and the rev will not be bumped, which seems incorrect.
See the discussion we have in bugzilla. The important point is that customers should always see a different package version if anything has changed. Which is fine for release products. But with FACTORY going out daily, we have to change the scripts for FACTORY to increase the revisions as needed, let's see how this can be done in the best way, Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
On Oct 02, 06 11:26:08 +0200, Robert Schiele wrote:
On Mon, Oct 02, 2006 at 10:14:22AM +0200, Andreas Jaeger wrote:
Robert Schiele
writes: No, you don't. You updated the db package (which is definitely part of the
That's a bug ;-(
Sorry, my fault. I skipped a few steps. Release numbers should be incremented on next sync now. cheers, Jw. -- o \ Juergen Weigert paint it green! __/ _=======.=======_ <V> | jw@suse.de wide open suse_/ _---|____________\/ \ | 0911 74053-508 (tm)__/ (____/ /\ (/) | __________________________/ _/ \_ vim:set sw=2 wm=8 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (11)
-
Andreas Jaeger
-
Christoph Thiel
-
Jon Nelson
-
JP Rosevear
-
Juergen Weigert
-
Pascal Bleser
-
Rene Salmon
-
Robert Schiele
-
Robert Schiele
-
Thomas Börkel
-
Tim Harper