Bug 1170709 - MicroOS-release does not own /etc/YaST2/control.xml
MicroOS-release does not own /etc/YaST2/control.xml
Status: CONFIRMED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: YaST2
Current
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: YaST Team
Jiri Srain
https://trello.com/c/TXeMXdnY/4119-wi...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2020-04-28 14:31 UTC by Ludwig Nussel
Modified: 2021-05-31 06:55 UTC (History)
4 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ludwig Nussel 2020-04-28 14:31:50 UTC
on MicroOS /etc/YaST2/control.xml is not owned by the release package. See also bug#404141
Comment 1 Thorsten Kukuk 2020-04-28 14:35:56 UTC
(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.
Comment 2 Ludwig Nussel 2020-04-28 14:50:04 UTC
So the bug needs to be moved to YaST to not install that file on MicroOS then?
Comment 4 Thorsten Kukuk 2020-04-29 08:22:28 UTC
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.
Comment 5 Josef Reidinger 2020-05-07 12:49:19 UTC
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 )
Comment 6 Thorsten Kukuk 2020-05-07 13:01:47 UTC
(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.
Comment 7 Ludwig Nussel 2020-05-07 13:13:59 UTC
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.
Comment 8 Lukas Ocilka 2020-05-07 14:11:22 UTC
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.

Thank you
Comment 9 Ludwig Nussel 2020-05-07 14:22:41 UTC
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.
Comment 10 Lukas Ocilka 2020-05-12 11:38:09 UTC
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
  to predict

All in all, it's again about use-cases.
Comment 11 Alberto Planas Dominguez 2021-05-25 12:54:54 UTC
# cat /etc/os-release | grep "ID="
ID="opensuse-microos"
VERSION_ID="20210522

# 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`.
Comment 12 Ludwig Nussel 2021-05-27 12:15:57 UTC
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.
Comment 13 Alberto Planas Dominguez 2021-05-28 08:02:54 UTC
I wonder if this bug also affect /etc/products.d/baseproduct. In openSUSE belong to the release package, but in MicroOS is not owned.
Comment 14 Josef Reidinger 2021-05-31 06:55:50 UTC
(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.