[yast-devel] Improving the YaST self-update
Hi all, I'm improving the YaST self-update [1] to avoid applying wrong patches to the installer (i.e. using the SP1 or SP3 update repository in the SP2 installer). I have already implemented the downgrade check [2] (e.g. using the SP1 updates in SP2), now I'd like to also implement the other check (using the future SP3 updates in SP2). However, this case is a bit more complicated, we need to somehow differ between the "new" (a valid update) and "too new" (update for a newer SP release) packages. And we need some reliable solution for that to avoid false errors. Here is a summary of my ideas, please comment them or add your own. 1. Compare the major and minor YaST package versions As the YaST package versions are bound to specific SP release (e.g. 4.1.x for SP1, 4.2.x for SP2) we could simply check that the updated package version has the same major and minor version as the installed one. I.e. allow a difference only in the patch number. But unfortunately this is not bullet-proof, we still have some YaST packages in version 4.1.x even in SP2. That should be hopefully fixed during branching SP2 in Git but it still shows that it's not 100% percent reliable. 2. The RPM "Distribution" value Every package has a "Distribution" flag (check with "rpm --queryformat '%{DISTRIBUTION}' -q ..." command). Unfortunately even for the SP2 the value is still "SUSE Linux Enterprise 15" so we cannot differ between the GA/SP1/SP2/... packages. :-/ And I think it would not work well with unofficial testing packages built in your OBS branch project as the "Distribution" then contains the "home:..." prefix. So testing would be more difficult. 3. Custom provides flag We could possibly use some custom RPM flag, something like "Provides: yast-self-update-version(15.2)" added when releasing a self-update. We could compare it with the value stored in the /etc/os-release file in the inst-sys. Because it's enough to have this flag only once in the self-update repository we would add it just to the first YaST package released as a self-update. The other package updates released later would not need to have this flag. I deliberately selected the "15.2" value which corresponds to the "VERSION_ID" tag in the /etc/os-release file because this is the same for both SLE-15-SP2 and Leap 15.2 so we could easily build the same self-update packages also for Leap 15.2 if needed. Any comments, ideas? Thank you in advance! [1] https://github.com/yast/yast-installation/blob/master/doc/SELF_UPDATE.md [2] https://github.com/yast/yast-installation/pull/842 -- Ladislav Slezák YaST Developer SUSE LINUX, s.r.o. Corso IIa Křižíkova 148/34 18600 Praha 8 -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Fri, 20 Mar 2020, Ladislav Slezak wrote:
I'm improving the YaST self-update [1] to avoid applying wrong patches to the installer (i.e. using the SP1 or SP3 update repository in the SP2 installer).
The installation system already knows which product it was built for. What's missing is that the self update repo says which product it is intended for. I think the self update should contain the information. We could require some hint in the repository meta data or a special package (like these xxx-release packages or simply a package named/providing selfupdate-for-foo-bar) that contains the info. Extending the yast side magic seems not to be the best solution to me. Rather be more explicit than implicit. Steffen -- Give orange me give eat orange me eat orange give me eat orange give me you. (chimp Nim, using sign language) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Hi, On 20. 03. 20 16:07, Ladislav Slezak wrote:
Hi all,
I'm improving the YaST self-update [1] to avoid applying wrong patches to the installer (i.e. using the SP1 or SP3 update repository in the SP2 installer).
I have already implemented the downgrade check [2] (e.g. using the SP1 updates in SP2), now I'd like to also implement the other check (using the future SP3 updates in SP2).
However, this case is a bit more complicated, we need to somehow differ between the "new" (a valid update) and "too new" (update for a newer SP release) packages. And we need some reliable solution for that to avoid false errors.
Here is a summary of my ideas, please comment them or add your own.
1. Compare the major and minor YaST package versions
As the YaST package versions are bound to specific SP release (e.g. 4.1.x for SP1, 4.2.x for SP2) we could simply check that the updated package version has the same major and minor version as the installed one. I.e. allow a difference only in the patch number.
But unfortunately this is not bullet-proof, we still have some YaST packages in version 4.1.x even in SP2. That should be hopefully fixed during branching SP2 in Git but it still shows that it's not 100% percent reliable.
It is even worse: The self-update is not limited to YaST packages (you can update any part of inst-sys). There the version scheme will fail (unless you introduce way more logic).
2. The RPM "Distribution" value
Every package has a "Distribution" flag (check with "rpm --queryformat '%{DISTRIBUTION}' -q ..." command).
Unfortunately even for the SP2 the value is still "SUSE Linux Enterprise 15" so we cannot differ between the GA/SP1/SP2/... packages. :-/
And I think it would not work well with unofficial testing packages built in your OBS branch project as the "Distribution" then contains the "home:..." prefix. So testing would be more difficult.
3. Custom provides flag
We could possibly use some custom RPM flag, something like "Provides: yast-self-update-version(15.2)" added when releasing a self-update. We could compare it with the value stored in the /etc/os-release file in the inst-sys.
If you work this idea a bit further, this is perhaps something that could also work with the quarterly re-spins (you could distinguish which package should apply to which quarterly release even if they are all in the same repository).
Because it's enough to have this flag only once in the self-update repository we would add it just to the first YaST package released as a self-update. The other package updates released later would not need to have this flag.
Well, not if you want to address quarter re-spins. Anyway, take it just as an idea, not a requirement from me. Jiri
I deliberately selected the "15.2" value which corresponds to the "VERSION_ID" tag in the /etc/os-release file because this is the same for both SLE-15-SP2 and Leap 15.2 so we could easily build the same self-update packages also for Leap 15.2 if needed.
Any comments, ideas?
Thank you in advance!
[1] https://github.com/yast/yast-installation/blob/master/doc/SELF_UPDATE.md [2] https://github.com/yast/yast-installation/pull/842
-- Regards, Jiri Srain Project Manager --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: jsrain@suse.com Krizikova 148/34 tel: +420 284 084 659 186 00 Praha 8 fax: +420 284 084 001 Czech Republic http://www.suse.com -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Dne 20. 03. 20 v 16:07 Ladislav Slezak napsal(a):
3. Custom provides flag
We could possibly use some custom RPM flag, something like "Provides: yast-self-update-version(15.2)" added when releasing a self-update. We could compare it with the value stored in the /etc/os-release file in the inst-sys.
Because it's enough to have this flag only once in the self-update repository we would add it just to the first YaST package released as a self-update. The other package updates released later would not need to have this flag.
I deliberately selected the "15.2" value which corresponds to the "VERSION_ID" tag in the /etc/os-release file because this is the same for both SLE-15-SP2 and Leap 15.2 so we could easily build the same self-update packages also for Leap 15.2 if needed.
4. Additional "Conflicts" flag This would be similar to the previous solution, but instead of custom "Provides" we could use more logical "Conflicts" dependency. This would also avoid using some non-standard "Provides" tag. For example when releasing a new "yast2-installation" self-update we would add "Conflicts: yast2 < 4.2.78" (or whatever version would be released in the SP2 GM). Then the self-update code would evaluate all conflict dependencies of the updated packages and report an error if some conflict is found. Advantages: - more logical - no special tag Disadvantages: - if the repository contains no YaST package yet we cannot easily add this conflict to the other packages (but sooner or later there will be an YaST update so this is rather a theoretical or short term problem) -- Ladislav Slezák YaST Developer SUSE LINUX, s.r.o. Corso IIa Křižíkova 148/34 18600 Praha 8 -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Dne 30. 03. 20 v 12:19 Steffen Winterfeldt napsal(a):
What's missing is that the self update repo says which product it is intended for.
Exactly. The problem is that repositories themselves do not contain any additional metadata describing them, the metadata can only describe the included packages. Otherwise the solution would be easy...
I think the self update should contain the information. We could require some hint in the repository meta data or a special package (like these xxx-release packages or simply a package named/providing selfupdate-for-foo-bar) that contains the info.
Using some *-release package for this purpose sounds like a good idea as well. We could compare the product ID in the /etc/os-release file in the inst-sys with the file from *-release package in the repository, they should be the same. If not we could easily display the user-friendly product data: PRETTY_NAME="SUSE Linux Enterprise 15 SP2" Unfortunately for the SLES installer it's a bit more complicated because the inst-sys contains the /etc/os-release file from the "unified-installer-release" package with the ID above. But that package is not released and the released "sles-release" package contains a different ID ("SLE" vs. "SLES"). So the question is whether the maintenance team could actually release a completely "new" package as a self-update... Alternatively the self-update repo could contain the published "sles-release" package and we would compare only the "VERSION_ID" value in the os-release file, the check would be less strict. This value is the same for all SLE products ("15.2") and is the same also in the "unified-installer-release" package -- Ladislav Slezák YaST Developer SUSE LINUX, s.r.o. Corso IIa Křižíkova 148/34 18600 Praha 8 -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Dne 31. 03. 20 v 8:59 Jiri Srain napsal(a):
It is even worse: The self-update is not limited to YaST packages (you can update any part of inst-sys). There the version scheme will fail (unless you introduce way more logic).
We could check only some specific YaST packages. (Actually that's already implemented in the existing downgrade check, we compare the versions only for some white-listed YaST packages, we do not care about the others.)
If you work this idea a bit further, this is perhaps something that could also work with the quarterly re-spins (you could distinguish which package should apply to which quarterly release even if they are all in the same repository).
Yes, but you would need to add it to *every* package, even to non-YaST packages, that would be a bit more difficult to enforce... -- Ladislav Slezák YaST Developer SUSE LINUX, s.r.o. Corso IIa Křižíkova 148/34 18600 Praha 8 -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 31. 03. 20 16:39, Ladislav Slezak wrote:
Dne 31. 03. 20 v 8:59 Jiri Srain napsal(a):
It is even worse: The self-update is not limited to YaST packages (you can update any part of inst-sys). There the version scheme will fail (unless you introduce way more logic).
We could check only some specific YaST packages.
(Actually that's already implemented in the existing downgrade check, we compare the versions only for some white-listed YaST packages, we do not care about the others.)
If you work this idea a bit further, this is perhaps something that could also work with the quarterly re-spins (you could distinguish which package should apply to which quarterly release even if they are all in the same repository).
Yes, but you would need to add it to *every* package, even to non-YaST packages, that would be a bit more difficult to enforce...
Or not. You could turn this Provides into an API to the maintenance team telling them that the update is supposed to go to a self-update :-) This would be something for longer discussion with maintenance, though. Jiri -- Regards, Jiri Srain Project Manager --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: jsrain@suse.com Krizikova 148/34 tel: +420 284 084 659 186 00 Praha 8 fax: +420 284 084 001 Czech Republic http://www.suse.com -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
participants (3)
-
Jiri Srain -
Ladislav Slezak -
Steffen Winterfeldt