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: jsr...@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+unsubscr...@opensuse.org
To contact the owner, e-mail: yast-devel+ow...@opensuse.org
