Bugzilla – Bug 1170709
MicroOS-release does not own /etc/YaST2/control.xml
Last modified: 2021-05-31 06:55:50 UTC
on MicroOS /etc/YaST2/control.xml is not owned by the release package. See also bug#404141
(In reply to Ludwig Nussel from comment #0)
> on MicroOS /etc/YaST2/control.xml is not owned by the release package. See
> also bug#404141
That bug is invalid for MicroOS as we don't support YaST running on it. The file shouldn't be installed. I don't see a sense in copying this file into the system if we have an RPM containing the official file.
So the bug needs to be moved to YaST to not install that file on MicroOS then?
yast copies other files too: https://github.com/yast/yast-installation/blob/master/src/lib/installation/clients/copy_files_finish.rb
According to the YaST code comments, the control.xml is only needed for the second stage installation. We don't have that, so YaST should not copy that file in this case.
well, control.xml is also used by YaST on runtime when user wants to repropose configuration. Control.xml defines product specific settings. So it is useful also for running YaST. We copy much more files, e.g. also installation logs, various settings and so on.
BTW regarding that rpm with file it is not so easy, as we plan to capture in that /etc/YaST2/control.xml also user selection of add-ons and system roles as all of it can affect final result. So it can be different then one from rpm. ( not now )
(In reply to Josef Reidinger from comment #5)
> BTW regarding that rpm with file it is not so easy, as we plan to capture in
> that /etc/YaST2/control.xml also user selection of add-ons and system roles
> as all of it can affect final result. So it can be different then one from
> rpm. ( not now )
So instead of changing MicroOS we need to change Tumbleweed to also not own the file.
That opens the original issue again, ie the file ends up containing outdated information after zypper dup then. The whole thing is a can of worms. Maybe we can find a way to not have /etc/YaST2/control.xml in it's current form at all?
We could still package the original in /usr for later use. Any add-ons, roles etc would be required to also ship their snippet in a unique file. That way would make sure that zypper dup updates those files with information that matches the distro.
Ludwig, could you, please, try to describe what is the problem here?
I mean: The real problem that MicroOS, TW, SLES or so runs into because
the file is there?
We currently assume that the file "might" be needed in the future (and often is).
Anything else is just a feature that might or might not pay off. The same
applies to copying other files or even logs too. We believe we need that
as it's been proven that in majority of cases, this was true. Extending the
functionality by decision making process what to copy or not and when needs
proper use-cases and planning.
So far there is no problem, just a random not owned file hanging around that won't get updated. Might turn into a problem in the future, esp when yast implements what Josef explained. So make sense to take the discussion here into consideration.
For the issue at hand, short of yast changing to not copy the file as Thorsten suggested I'd go for the "solution" that is used so far in the main product, ie just own control.xml in a package. That way at least we won't have a stale, not owned file hanging around.
Looking at it from the distance now, there are at least these points:
- The file is needed for YaST (contains some settings)
- The file should contain more up-to-date settings (modules, roles, ...)
- The file should be owned by YaST (or the product)
- We may also reconsider switching to sysconfig file
- This is a major change
But then we would need to solve other problems
- If YaST is not going to be installed, we might or might not write it
to the resulting system
- But YaST can be usually installed later and we'd miss the settings from
installation, depends what we need to have, this is close to impossible
All in all, it's again about use-cases.
# cat /etc/os-release | grep "ID="
# rpm -qf /etc/YaST2/control.xml
file /etc/YaST2/control.xml is not owned by any package
I have an use case for this file, and should avoid future problems if this file is owned by MicroOS-release, or other package (MicroOS-YaST, maybe).
The problem that will avoid is that if the set of default patterns change for a role, this file will not be updated to reflect the new relation. This will break badly a new feature on planning for `transactional-update`.
I get impression that this turns into a changing understanding of the file. It's somehow mixing presets for an installer (might be yast) with recording what actually happened during installation. Maybe the different purposes need to be separated. A major change indeed.
I wonder if this bug also affect /etc/products.d/baseproduct. In openSUSE belong to the release package, but in MicroOS is not owned.
(In reply to Ludwig Nussel from comment #12)
> I get impression that this turns into a changing understanding of the file.
> It's somehow mixing presets for an installer (might be yast) with recording
> what actually happened during installation. Maybe the different purposes
> need to be separated. A major change indeed.
agreed. We already discuss that it would be nice to write final control file after all changes done by applying various product/add-on/role specific changes to defaults. But it is a new feature from yast POV.