Upgrade to Leap 15.3 needs 2 steps
Hi, I recently ugraded 2 Leap 15.2 machines and noticed, that after the zypper --releasever 15.3 dup --allow-vendor-change the system is upgraded, but the latest patches are not applied. Another zypper up is required (giving another ~1GB download!). Is this a bug (sounds like) or a feature? If feature, what is the rationale behind? When running an online upgrade my expectation is that latest packages are installed..... Cheers Axel
Axel Braun composed on 2021-10-27 20:59 (UTC+0200):
I recently ugraded 2 Leap 15.2 machines and noticed, that after the zypper --releasever 15.3 dup --allow-vendor-change the system is upgraded, but the latest patches are not applied. Another zypper up is required (giving another ~1GB download!).
Is this a bug (sounds like) or a feature?
If feature, what is the rationale behind? When running an online upgrade my expectation is that latest packages are installed.....
My recollection could be wrong, but I think the repo for baseurl=http://download.opensuse.org/update/leap/15.3/backports/ is missing until after AFTER the dup. It's been several weeks since I dup'd from 15.2 to 15.3. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On 27/10/2021 20.59, Axel Braun wrote:
Hi,
I recently ugraded 2 Leap 15.2 machines and noticed, that after the zypper --releasever 15.3 dup --allow-vendor-change the system is upgraded, but the latest patches are not applied. Another zypper up is required (giving another ~1GB download!).
Is this a bug (sounds like) or a feature?
If feature, what is the rationale behind? When running an online upgrade my expectation is that latest packages are installed.....
I suspect that after the first dup the new repositories coming from SLE are added to the configuration, and thus you need a second dup to apply them. I think that the instructions have to be modified to manually add those new repos before starting the upgrade. I have not done yet the upgrade of any of my machines (I'm busy), so I have not been able to test my idea in a virtual machine. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 2021-10-27 12:59 p.m., Axel Braun wrote:
Hi,
I recently ugraded 2 Leap 15.2 machines and noticed, that after the zypper --releasever 15.3 dup --allow-vendor-change the system is upgraded, but the latest patches are not applied. Another zypper up is required (giving another ~1GB download!).
Is this a bug (sounds like) or a feature?
If feature, what is the rationale behind? When running an online upgrade my expectation is that latest packages are installed.....
I did the upgrade from a USB stick. The new repos were added before the upgrade began. You can also choose to keep existing 3rd party repos like Packman (editing the url, of course, to point to the proper repo).
On 28/10/2021 10:14, Darryl Gregorash wrote:
On 2021-10-27 12:59 p.m., Axel Braun wrote:
Hi,
I recently ugraded 2 Leap 15.2 machines and noticed, that after the zypper --releasever 15.3 dup --allow-vendor-change the system is upgraded, but the latest patches are not applied. Another zypper up is required (giving another ~1GB download!).
Is this a bug (sounds like) or a feature?
If feature, what is the rationale behind? When running an online upgrade my expectation is that latest packages are installed.....
I did the upgrade from a USB stick. The new repos were added before the upgrade began. You can also choose to keep existing 3rd party repos like Packman (editing the url, of course, to point to the proper repo).
Forgive me if I ask idiot questions, but "from a USB stick" means "from a bootable installation image on a USB stick", right? I also use Packman and other update repos that don't accept the releasever parameter. At what point in the upgrade process 15.2 to 15.3 does one get to edit these URLs manually? -- Robin K Wellington "Harbour City" New Zealand
On 2021-10-27 8:57 p.m., Robin Klitscher wrote:
On 28/10/2021 10:14, Darryl Gregorash wrote:
I did the upgrade from a USB stick. The new repos were added before the upgrade began. You can also choose to keep existing 3rd party repos like Packman (editing the url, of course, to point to the proper repo).
Forgive me if I ask idiot questions, but "from a USB stick" means "from a bootable installation image on a USB stick", right?
Yes.
I also use Packman and other update repos that don't accept the releasever parameter. At what point in the upgrade process 15.2 to 15.3 does one get to edit these URLs manually?
I can assure you that any repo that has the version number in it can be edited to use releasever. Just edit the repo url to replace 15.x with $releasever. You can do that in Yast/Repositories if you wish, to verify that it does work. Yast/zypper/whatever will replace the parameter with the current release version. This is what you will see: URL: http://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Leap_15.3/ Raw URL: http://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Leap_$releasever/ I don't recall exactly where in the upgrade process the repo selection occurs, but it is quite early -- before software selection iirc. Also, before teh upgrade actually begins, you always have a chance to go back and make changes if you wish.
Am Donnerstag, 28. Oktober 2021, 06:56:06 CEST schrieb Darryl Gregorash:
On 2021-10-27 8:57 p.m., Robin Klitscher wrote:
....
I also use Packman and other update repos that don't accept the releasever parameter. At what point in the upgrade process 15.2 to 15.3 does one get to edit these URLs manually?
I can assure you that any repo that has the version number in it can be edited to use releasever. Just edit the repo url to replace 15.x with $releasever. You can do that in Yast/Repositories if you wish, to verify that it does work. Yast/zypper/whatever will replace the parameter with the current release version. This is what you will see:
URL: http://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Leap_15.3/ Raw URL: http://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Leap_$releasever/
sed -i -e 's/15.2/\$releasever/g' /etc/zypp/repos.d/*.repo does the job quite convenient Cheers Axel
Axel Braun composed on 2021-10-28 08:16 (UTC+0200):
sed -i -e 's/15.2/\$releasever/g' /etc/zypp/repos.d/*.repo
does the job quite convenient But why? What advantage is there to a long-winded variable over a short literal? -- Evolution as taught in public schools is, like religion, based on faith, not based on science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On 2021-10-28 12:42 a.m., Felix Miata wrote:
Axel Braun composed on 2021-10-28 08:16 (UTC+0200):
sed -i -e 's/15.2/\$releasever/g' /etc/zypp/repos.d/*.repo
does the job quite convenient But why? What advantage is there to a long-winded variable over a short literal?
Do you enjoy editing the repo urls every time you do a version upgrade? I don't.
Darryl Gregorash composed on 2021-10-28 00:48 (UTC-0600):
Felix Miata wrote:
Axel Braun composed on 2021-10-28 08:16 (UTC+0200):
sed -i -e 's/15.2/\$releasever/g' /etc/zypp/repos.d/*.repo
does the job quite convenient But why? What advantage is there to a long-winded variable over a short literal?
Do you enjoy editing the repo urls every time you do a version upgrade? I don't.
There's nothing to enjoy or not. I run a sed command once per Leap release …/Suse/153# sed -i 's/15.2/15.3/g' *.repo* then stamp them with a timestamp visually equal to the releasever, and copy the set from my LAN server to each installation, which is typically upwards of 20. Any time I see a timestamp on a repo file that isn't as I made it, it's something to investigate: /etc/zypp/repos.d# ls -Gg *repo -rw-r--r-- 1 137 Jun 2 15:03 Libdvdcss.repo -rw-r--r-- 1 268 Jun 2 15:03 Mozilla.repo -rw-r--r-- 1 153 Jun 2 15:03 NonOSS.repo -rw-r--r-- 1 143 Jun 2 15:03 OSS.repo -rw-r--r-- 1 255 Jun 2 15:03 PackmanE.repo -rw-r--r-- 1 176 Jun 2 15:03 TDEnoarch.repo -rw-r--r-- 1 164 Jun 2 15:03 TDE.repo -rw-r--r-- 1 240 Jul 27 15:03 UpdateBP.repo -rw-r--r-- 1 129 Jun 2 15:03 Update.repo -rw-r--r-- 1 135 Jun 2 15:03 UpdateSLE.repo -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On 28/10/2021 09.25, Felix Miata wrote:
Darryl Gregorash composed on 2021-10-28 00:48 (UTC-0600):
Felix Miata wrote:
Axel Braun composed on 2021-10-28 08:16 (UTC+0200):
sed -i -e 's/15.2/\$releasever/g' /etc/zypp/repos.d/*.repo
does the job quite convenient But why? What advantage is there to a long-winded variable over a short literal?
Do you enjoy editing the repo urls every time you do a version upgrade? I don't.
There's nothing to enjoy or not. I run a sed command once per Leap release
…/Suse/153# sed -i 's/15.2/15.3/g' *.repo*
And with the new method you do it only once per lifetime. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 2021-10-28 1:25 a.m., Felix Miata wrote:
Darryl Gregorash composed on 2021-10-28 00:48 (UTC-0600):
Do you enjoy editing the repo urls every time you do a version upgrade? I don't.
There's nothing to enjoy or not. I run a sed command once per Leap release
…/Suse/153# sed -i 's/15.2/15.3/g' *.repo*
then stamp them with a timestamp visually equal to the releasever, and copy the set from my LAN server to each installation, which is typically upwards of 20. Any time I see a timestamp on a repo file that isn't as I made it, it's something to investigate:
/etc/zypp/repos.d# ls -Gg *repo <snip>
Carlos's observation of "once per lifetime" still applies: …/Suse/153# sed -i 's/15.2/$releasever/g' *.repo* then copy the set to each installation, and you are done for life. The timestamp on any repo file no longer matters, because Yast/zypper/whatever automatically translates the variable name into the current release version number. You no longer need to concern yourself with when the file was last edited.
On 28/10/2021 14.13, Darryl Gregorash wrote:
On 2021-10-28 1:25 a.m., Felix Miata wrote:
Darryl Gregorash composed on 2021-10-28 00:48 (UTC-0600):
Do you enjoy editing the repo urls every time you do a version upgrade? I don't.
There's nothing to enjoy or not. I run a sed command once per Leap release
…/Suse/153# sed -i 's/15.2/15.3/g' *.repo*
then stamp them with a timestamp visually equal to the releasever, and copy the set from my LAN server to each installation, which is typically upwards of 20. Any time I see a timestamp on a repo file that isn't as I made it, it's something to investigate:
/etc/zypp/repos.d# ls -Gg *repo <snip>
Carlos's observation of "once per lifetime" still applies:
…/Suse/153# sed -i 's/15.2/$releasever/g' *.repo*
then copy the set to each installation, and you are done for life. The timestamp on any repo file no longer matters, because Yast/zypper/whatever automatically translates the variable name into the current release version number. You no longer need to concern yourself with when the file was last edited.
To detect errors you could use: grep "15.2\|15.3" *repo -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
Darryl Gregorash composed on 2021-10-28 06:13 (UTC-0600):
You no longer need to concern yourself with when the file was last edited.
There are several reasons I may become concerned if a repo file has been changed. I manage mine with MC and FCL, and don't want anything messing with them. I like to see a number instead of a variable, so I can live with a once per release edit. It's incidental to other things. And with a number rather than a variable, they are unique to the distro, like /etc/os-release is. I like that. Fedora's long time use of variables in repo files is one of the lesser reasons I like openSUSE more than Fedora. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On 2021-10-28 6:33 a.m., Felix Miata wrote:
Darryl Gregorash composed on 2021-10-28 06:13 (UTC-0600):
You no longer need to concern yourself with when the file was last edited.
There are several reasons I may become concerned if a repo file has been changed. I manage mine with MC and FCL, and don't want anything messing with them.
What could possibly change a repo file?
I like to see a number instead of a variable, so I can live with a once per....
If that's your preference, fine.
release edit. It's incidental to other things. And with a number rather than a variable, they are unique to the distro, like /etc/os-release is. I like that. Fedora's long time use of variables in repo files is one of the lesser reasons I like openSUSE more than Fedora.
~ # zypper -u lr <snip> 1 | Libdvdcss | Libdvdcss Repository | ... | http://opensuse-guide.org/repo/openSUSE_Leap_15.3/ <snip> Like I said, zypper and Yast automatically translate $releasever into whatever is the current release version number.
Darryl Gregorash composed on 2021-10-28 07:31 (UTC-0600):
Felix Miata wrote:
Darryl Gregorash composed on 2021-10-28 06:13 (UTC-0600):
You no longer need to concern yourself with when the file was last edited.
There are several reasons I may become concerned if a repo file has been changed. I manage mine with MC and FCL, and don't want anything messing with them.
What could possibly change a repo file?
It happens, such as when the mirrors are fubar, and zypper decides to disable a repo it can't update, or 4 additional repos get added that duplicate existing repos with less stupid names than repo-....repo. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On 2021-10-28 11:44 a.m., Felix Miata wrote:
Darryl Gregorash composed on 2021-10-28 07:31 (UTC-0600):
Felix Miata wrote:
Darryl Gregorash composed on 2021-10-28 06:13 (UTC-0600):
You no longer need to concern yourself with when the file was last edited.
There are several reasons I may become concerned if a repo file has been changed. I manage mine with MC and FCL, and don't want anything messing with them.
What could possibly change a repo file?
It happens, such as when the mirrors are fubar, and zypper decides to disable a repo it can't update, or 4 additional repos get added that duplicate existing repos with less stupid names than repo-....repo.
Just how often do either of these happen? I have never seen either of them. Besides, if your repos go pear-shaped, Yast is your friend.
Darryl Gregorash composed on 2021-10-28 14:24 (UTC-0600):
Felix Miata wrote:
Darryl Gregorash composed on 2021-10-28 07:31 (UTC-0600):
What could possibly change a repo file?
It happens, such as when the mirrors are fubar, and zypper decides to disable a repo it can't update, or 4 additional repos get added that duplicate existing repos with less stupid names than repo-....repo.
Just how often do either of these happen? I have never seen either of them.
I don't log such occurrences. Suffice to say both types mentioned above have happened more than thrice since the first of this year. On one installation I went so far as to set the immutable flag on all repo files (or was it on /etc/zypp/repos.d/?). -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On 2021-10-28 12:16 a.m., Axel Braun wrote:
Am Donnerstag, 28. Oktober 2021, 06:56:06 CEST schrieb Darryl Gregorash:
On 2021-10-27 8:57 p.m., Robin Klitscher wrote:
....
I also use Packman and other update repos that don't accept the releasever parameter. At what point in the upgrade process 15.2 to 15.3 does one get to edit these URLs manually?
I can assure you that any repo that has the version number in it can be edited to use releasever. Just edit the repo url to replace 15.x with $releasever. You can do that in Yast/Repositories if you wish, to verify that it does work. Yast/zypper/whatever will replace the parameter with the current release version. This is what you will see:
URL: http://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Leap_15.3/ Raw URL: http://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Leap_$releasever/
sed -i -e 's/15.2/\$releasever/g' /etc/zypp/repos.d/*.repo
does the job quite convenient
Cheers Axel
But using Yast doesn't require one to remember what for most people is an obscure command with a difficult syntax, nor where the repo files are stored :D
Am Donnerstag, 28. Oktober 2021, 08:46:39 CEST schrieb Darryl Gregorash:
On 2021-10-28 12:16 a.m., Axel Braun wrote:
URL: http://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Leap_15.3/ Raw URL: http://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Leap_$releasever/
sed -i -e 's/15.2/\$releasever/g' /etc/zypp/repos.d/*.repo
does the job quite convenient
But using Yast doesn't require one to remember what for most people is an obscure command with a difficult syntax, nor where the repo files are stored :D
Sure. There is always a break-even between the GUI mode in YaST or the command line mode. The more repos/systems you have to update, the more you prefer the CLI mode :-) Cheers Axel
On 28/10/2021 08.46, Darryl Gregorash wrote:
On 2021-10-28 12:16 a.m., Axel Braun wrote:
Am Donnerstag, 28. Oktober 2021, 06:56:06 CEST schrieb Darryl Gregorash:
On 2021-10-27 8:57 p.m., Robin Klitscher wrote:
....
I also use Packman and other update repos that don't accept the releasever parameter. At what point in the upgrade process 15.2 to 15.3 does one get to edit these URLs manually?
I can assure you that any repo that has the version number in it can be edited to use releasever. Just edit the repo url to replace 15.x with $releasever. You can do that in Yast/Repositories if you wish, to verify that it does work. Yast/zypper/whatever will replace the parameter with the current release version. This is what you will see:
URL: http://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Leap_15.3/ Raw URL: http://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Leap_$releasever/
sed -i -e 's/15.2/\$releasever/g' /etc/zypp/repos.d/*.repo
does the job quite convenient
But using Yast doesn't require one to remember what for most people is an obscure command with a difficult syntax, nor where the repo files are stored :D
Using yast means you have to edit them every year, as compared to one per lifetime in CLI - as long as you never edit them in YaST. But new repositories will be wrong. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 2021-10-28 4:45 a.m., Carlos E. R. wrote:
On 28/10/2021 08.46, Darryl Gregorash wrote:
But using Yast doesn't require one to remember what for most people is an obscure command with a difficult syntax, nor where the repo files are stored :D
Using yast means you have to edit them every year, as compared to one per lifetime in CLI - as long as you never edit them in YaST.
But new repositories will be wrong.
What on earth are you talking about? Once a repo has $releasever in it instead of the version number, it never needs to be edited again. It does not matter how that edit is done. I have no idea what you mean by new repositories being wrong. If they are wrong, then whoever added them to the system made a mistake.
On 28/10/2021 13.47, Darryl Gregorash wrote:
On 2021-10-28 4:45 a.m., Carlos E. R. wrote:
On 28/10/2021 08.46, Darryl Gregorash wrote:
But using Yast doesn't require one to remember what for most people is an obscure command with a difficult syntax, nor where the repo files are stored :D
Using yast means you have to edit them every year, as compared to one per lifetime in CLI - as long as you never edit them in YaST.
But new repositories will be wrong.
What on earth are you talking about?
Once a repo has $releasever in it instead of the version number,
Once! New repos will not have $releasever.
it never needs to be edited again. It does not matter how that edit is done. I have no idea what you mean by new repositories being wrong. If they are wrong, then whoever added them to the system made a mistake.
When we create a new repo with YaST, it will not have $releasever because the actual URL we copy paste doesn't have it. Unless we are aware at that moment in time, months away from updating, that we should change the name with $releasever. Notice that repos can also be automaticall be added by tools like "one click" or "opi", and I guess those tools do not write them with $releasever. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 2021-10-28 6:10 a.m., Carlos E. R. wrote:
On 28/10/2021 13.47, Darryl Gregorash wrote:
Once a repo has $releasever in it instead of the version number,
Once! New repos will not have $releasever.
Oh, come on, Carlos. Just change <version number> to $releasever as you are adding the new repo.
it never needs to be edited again. It does not matter how that edit is done. I have no idea what you mean by new repositories being wrong. If they are wrong, then whoever added them to the system made a mistake.
When we create a new repo with YaST, it will not have $releasever because the actual URL we copy paste doesn't have it.
Ibid. And if you add a new repo via "one click" or whatever, just go into Yast (or use sed if you prefer) immediately and make the edit manually.
Unless we are aware at that moment in time, months away from updating, that we should change the name with $releasever.
The release version number is in the overwhelming majority of repo urls you will ever encounter. If you leave it alone, you will always need to change it some months away == so why not do it right away as a matter of habit?
On 28/10/2021 14.20, Darryl Gregorash wrote:
On 2021-10-28 6:10 a.m., Carlos E. R. wrote:
On 28/10/2021 13.47, Darryl Gregorash wrote:
Once a repo has $releasever in it instead of the version number,
Once! New repos will not have $releasever.
Oh, come on, Carlos. Just change <version number> to $releasever as you are adding the new repo.
I probably will, if I remember. Will everybody?
it never needs to be edited again. It does not matter how that edit is done. I have no idea what you mean by new repositories being wrong. If they are wrong, then whoever added them to the system made a mistake.
When we create a new repo with YaST, it will not have $releasever because the actual URL we copy paste doesn't have it.
Ibid. And if you add a new repo via "one click" or whatever, just go into Yast (or use sed if you prefer) immediately and make the edit manually.
That is a difficulty and breaks completely the point of using tools like oneclick.
Unless we are aware at that moment in time, months away from updating, that we should change the name with $releasever.
The release version number is in the overwhelming majority of repo urls you will ever encounter. If you leave it alone, you will always need to change it some months away == so why not do it right away as a matter of habit?
I may. I may not remember the exact syntax at that moment and postpone. Will everybody? The point is, we have added more work for the admin :-p -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
Can we come back to the original topic, please?
Schöne Grüße
Axel
--
Written from cell phone - excuses for typos
Am 28. Oktober 2021 14:37:05 MESZ schrieb "Carlos E. R."
On 28/10/2021 14.20, Darryl Gregorash wrote:
On 2021-10-28 6:10 a.m., Carlos E. R. wrote:
On 28/10/2021 13.47, Darryl Gregorash wrote:
Once a repo has $releasever in it instead of the version number,
Once! New repos will not have $releasever.
Oh, come on, Carlos. Just change <version number> to $releasever as you are adding the new repo.
I probably will, if I remember. Will everybody?
it never needs to be edited again. It does not matter how that edit is done. I have no idea what you mean by new repositories being wrong. If they are wrong, then whoever added them to the system made a mistake.
When we create a new repo with YaST, it will not have $releasever because the actual URL we copy paste doesn't have it.
Ibid. And if you add a new repo via "one click" or whatever, just go into Yast (or use sed if you prefer) immediately and make the edit manually.
That is a difficulty and breaks completely the point of using tools like oneclick.
Unless we are aware at that moment in time, months away from updating, that we should change the name with $releasever.
The release version number is in the overwhelming majority of repo urls you will ever encounter. If you leave it alone, you will always need to change it some months away == so why not do it right away as a matter of habit?
I may. I may not remember the exact syntax at that moment and postpone.
Will everybody?
The point is, we have added more work for the admin :-p
Am Donnerstag, 28. Oktober 2021, 15:00:47 CEST schrieb Andrei Borzenkov:
Original topic was already answered. Two additional update repositories were added with the updated package (openSUSE-release), which explains why they are not present initially.
Ah, openSUSE-release provides the needed repos.... I tried a little dirty hack, and it worked: zypper clean zypper --releasever 15.3 ref zypper --releasever 15.3 in openSUSE-release (allow installation of openSUSE-release-15.3 + ~ 5 dependent packages - do not reboot now!) zypper --releasever 15.3 dup --allow-vendor-change After reboot the system came up as Leap 15.3, and no additional update required! Cheers Axel
On 2021-10-28 6:37 a.m., Carlos E. R. wrote:
On 28/10/2021 14.20, Darryl Gregorash wrote:
On 2021-10-28 6:10 a.m., Carlos E. R. wrote:
On 28/10/2021 13.47, Darryl Gregorash wrote:
Once a repo has $releasever in it instead of the version number,
Once! New repos will not have $releasever.
Oh, come on, Carlos. Just change <version number> to $releasever as you are adding the new repo.
I probably will, if I remember. Will everybody?
Get into the habit, and you will remember.
Ibid. And if you add a new repo via "one click" or whatever, just go into Yast (or use sed if you prefer) immediately and make the edit manually.
That is a difficulty and breaks completely the point of using tools like oneclick.
No, it does not. One click is still a useful tool; you simply (optionally, of course) change the repo url if you will be using it going forward, ie. into the next release.
The release version number is in the overwhelming majority of repo urls you will ever encounter. If you leave it alone, you will always need to change it some months away == so why not do it right away as a matter of habit?
I may. I may not remember the exact syntax at that moment and postpone.
Will everybody?
The point is, we have added more work for the admin :-p
I submit it's a lot less work than running sed on the cli with every upgrade, then copying the new file versions over the LAN to a multiplicity of client installations.
On 28/10/2021 15.36, Darryl Gregorash wrote:
On 2021-10-28 6:37 a.m., Carlos E. R. wrote:
...
The release version number is in the overwhelming majority of repo urls you will ever encounter. If you leave it alone, you will always need to change it some months away == so why not do it right away as a matter of habit?
I may. I may not remember the exact syntax at that moment and postpone.
Will everybody?
The point is, we have added more work for the admin :-p
I submit it's a lot less work than running sed on the cli with every upgrade, then copying the new file versions over the LAN to a multiplicity of client installations.
I always did and will continue doing, looking at the repo list carefully before doing an upgrade - example: grep "15.2\" *repo And probably edit the files that need modification, not paste the sed concoction which I would first have to find in the wiki or my notes. Also, as each machine has a different repo list, I never copy the files from one installation to another. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 2021-10-28 8:04 a.m., Carlos E. R. wrote:
And probably edit the files that need modification, not paste the sed concoction which I would first have to find in the wiki or my notes.
I still maintain it's easier to edit a new repo url when you add it, not wait until the next upgrade.
Also, as each machine has a different repo list, I never copy the files from one installation to another.
But once you have replace actual version numbers with $releasever on every machine, you never need to copy anything anywhere -- "once per lifetime", remember? Besides which, every installation will have a common set of repos -- the main, main update, and so on. The remainder, specific to each machine, won't be altered if you did choose to copy the common files from the server.
On 28/10/2021 16.19, Darryl Gregorash wrote:
On 2021-10-28 8:04 a.m., Carlos E. R. wrote:
And probably edit the files that need modification, not paste the sed concoction which I would first have to find in the wiki or my notes.
I still maintain it's easier to edit a new repo url when you add it, not wait until the next upgrade.
If I remember the concoction.
Also, as each machine has a different repo list, I never copy the files from one installation to another.
But once you have replace actual version numbers with $releasever on every machine, you never need to copy anything anywhere -- "once per lifetime", remember?
Sure, but I stil have to verify that it is so before doing the upgrade, nonetheless ;-)
Besides which, every installation will have a common set of repos -- the main, main update, and so on. The remainder, specific to each machine, won't be altered if you did choose to copy the common files from the server.
Yes, there are some that should be the same, but the literal definitions are not the same. Depends on the year of installation, there are little changes. I know because once I tried to align them on all my machines. Did not go well. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 2021-10-28 8:54 a.m., Carlos E. R. wrote:
On 28/10/2021 16.19, Darryl Gregorash wrote:
On 2021-10-28 8:04 a.m., Carlos E. R. wrote:
And probably edit the files that need modification, not paste the sed concoction which I would first have to find in the wiki or my notes.
I still maintain it's easier to edit a new repo url when you add it, not wait until the next upgrade.
If I remember the concoction.
Then do it in Yast, duh. OMG, Carlos, for someone who only recently posted "once in a lifetime", you are sure trying your best to argue why this should *not* be done.
Also, as each machine has a different repo list, I never copy the files from one installation to another.
But once you have replace actual version numbers with $releasever on every machine, you never need to copy anything anywhere -- "once per lifetime", remember?
Sure, but I stil have to verify that it is so before doing the upgrade, nonetheless ;-)
In Yast/Repositories: URL: http://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Leap_15.3/ Raw URL: http://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Leap_$releasever/ Or (for any previous installation to 15.3), run zypper lr -u followed by zypper --releasever 15.3 lr -u
Besides which, every installation will have a common set of repos -- the main, main update, and so on. The remainder, specific to each machine, won't be altered if you did choose to copy the common files from the server.
Yes, there are some that should be the same, but the literal definitions are not the same. Depends on the year of installation, there are little changes.
I know because once I tried to align them on all my machines. Did not go well.
Are you even trying to suggest that the Main (both OSS and non-OSS) and all the Update repositories are dependent on what time of year it is? You'll have to do much better than this.
On 28/10/2021 22.22, Darryl Gregorash wrote:
On 2021-10-28 8:54 a.m., Carlos E. R. wrote:
On 28/10/2021 16.19, Darryl Gregorash wrote:
On 2021-10-28 8:04 a.m., Carlos E. R. wrote:
And probably edit the files that need modification, not paste the sed concoction which I would first have to find in the wiki or my notes.
I still maintain it's easier to edit a new repo url when you add it, not wait until the next upgrade.
If I remember the concoction.
Then do it in Yast, duh. OMG, Carlos, for someone who only recently posted "once in a lifetime", you are sure trying your best to argue why this should *not* be done.
Apologies. I'm not saying it should not be done, I simply recognize that there are difficulties. I write $releasever on all my repo files. The $relasever thing saves me editing time, but nevertheless I do a careful evaluation of all repos before doing an upgrade. With good reason, I have to correct these on this computer:
Telcontar:~ # grep "15.2" /etc/zypp/repos.d/*repo /etc/zypp/repos.d/LocalRPMs_15.2.repo:[LocalRPMs_15.2] /etc/zypp/repos.d/LocalRPMs_15.2.repo:name=LocalRPMs_15.2 /etc/zypp/repos.d/LocalRPMs_15.2.repo:baseurl=dir:/data/storage_c/repositorios_zypp/LocalRPMs_15.2 /etc/zypp/repos.d/OBS_network_utilities.repo:baseurl=https://download.opensuse.org/repositories/network:utilities/openSUSE_Leap_1... Telcontar:~ #
Still, it is not all the files I have to edit. ...
Are you even trying to suggest that the Main (both OSS and non-OSS) and all the Update repositories are dependent on what time of year it is? You'll have to do much better than this.
No. I just say that different installs, done on different years, got different names for the 4 main repos, somehow. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
participants (8)
-
Andrei Borzenkov -
Axel Braun -
Axel Braun -
Axel Braun
-
Carlos E. R. -
Darryl Gregorash -
Felix Miata -
Robin Klitscher