action #11458
Updated by okurz almost 8 years ago
For details see https://fate.suse.com/319716
First check if the Feature status is "done".
Problem Description
We've seen several issues with broken installer, and not always caused by installer itself - sometimes it was caused by the changed environment, such as new feature of SCC or new list of online products. Something that we were unable to find out or think of when we designed the code. Obviously also bugs happen.
The Basic Idea
Installer should be able to setup network and then try to download its own (free) update (without registration) and update itself on-the-fly. This might need special support on SMT side.
Main Requirements
Do not overengineer, do not overcomplicate
Three scenarios for update URL: SCC, SMT, manually added URL (for testing purpose, QA/QAM)
Just one type of self-update: Update installer, restart installer
Customers' DUD on Linuxrc commandline has higer priority (L3)
The feature / new DUD must be easy to test
Functionality enabled by default, but possible to disable it easily
Technical Requirements (TBD, now they are mostly tasks/questions to decide)
SMT must be able to mirror these updates, ideally without any change of the SMT code
[TBD] Update format - DUD or RPM or ...? (See SMT, RPM could be bigger), RPM-MD or Yast format of metadata?
Implemented in Yast: Linuxrc often do not setup network or does not support all networking types
[TBD] When network is not set up, ask user?
[TBD] Define the default URL in control file, but change it if SMT is in use - similarly to registration?
[TBD] One DUD/RPM being rebuilt all the time or incrementally adding more one by one?
Do not use these DUDs anywhere else (e.g., as an install repo), just for updating the installer
This would solve us quite some headache in AutoYast and DUD area as customers would just not need to use these DUDs at all. Additionally, many P1s in RC phase could be P2 or P3s and later fixed by an update.