|
Bugzilla – Full Text Bug Listing |
| Summary: | yast2-installation: remove not needed dependencies | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Distribution | Reporter: | Ludwig Nussel <lnussel> |
| Component: | YaST2 | Assignee: | E-mail List <yast2-maintainers> |
| Status: | RESOLVED WONTFIX | QA Contact: | Jiri Srain <jsrain> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | kanderssen, lnussel, locilka, snwint |
| Version: | Leap 15.2 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| See Also: | http://bugzilla.suse.com/show_bug.cgi?id=1154238 | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Ludwig Nussel
2019-10-24 09:52:46 UTC
> So I think they should be safe to remove as dependency of yast2-installation.
Um, the dependencies are also used for building the inst-sys, to have all needed YaST packages there.
But actually the yast2-installation package should not be needed in the installed system (unless you need firstboot or AutoYaST second stage). So the correct fix should be to avoid installing yast2-installation in the first place.
But that still might not be enough, these packages might get installed by some default patterns or by other dependencies.
I do not know to cleanly solve this, we probably need some code in YaST which would detect the WSL environment and deselect that packages... ??
(In reply to Ladislav Slezák from comment #1) > > So I think they should be safe to remove as dependency of yast2-installation. > > Um, the dependencies are also used for building the inst-sys, to have all > needed YaST packages there. Well, that can be solved in installation-images by listing the required packages explicitly. > But actually the yast2-installation package should not be needed in the > installed system (unless you need firstboot or AutoYaST second stage). So That's the point, I've added yast2 firstboot to WSL :-) > But that still might not be enough, these packages might get installed by > some default patterns or by other dependencies. Indeed the yast pattern pulls it in also. > I do not know to cleanly solve this, we probably need some code in YaST > which would detect the WSL environment and deselect that packages... ?? So the image starts, runs firstboot and then deinstalls yast packages? I think the cleaner way would be to avoid having unneeded packages in the image in the first place. (In reply to Ludwig Nussel from comment #2) > (In reply to Ladislav Slezák from comment #1) > > > So I think they should be safe to remove as dependency of yast2-installation. > > > > Um, the dependencies are also used for building the inst-sys, to have all > > needed YaST packages there. > > Well, that can be solved in installation-images by listing the required > packages explicitly. What about modifying the spec file based in a macro and checking if it is wsl or not. Coult be that an option? > > > But actually the yast2-installation package should not be needed in the > > installed system (unless you need firstboot or AutoYaST second stage). So > > That's the point, I've added yast2 firstboot to WSL :-) > > > But that still might not be enough, these packages might get installed by > > some default patterns or by other dependencies. > > Indeed the yast pattern pulls it in also. > > > I do not know to cleanly solve this, we probably need some code in YaST > > which would detect the WSL environment and deselect that packages... ?? > > So the image starts, runs firstboot and then deinstalls yast packages? I > think the cleaner way would be to avoid having unneeded packages in the > image in the first place. (In reply to Knut Alejandro Anderssen González from comment #3) > (In reply to Ludwig Nussel from comment #2) > > (In reply to Ladislav Slezák from comment #1) > > > > So I think they should be safe to remove as dependency of yast2-installation. > > > > > > Um, the dependencies are also used for building the inst-sys, to have all > > > needed YaST packages there. > > > > Well, that can be solved in installation-images by listing the required > > packages explicitly. > > What about modifying the spec file based in a macro and checking if it is > wsl or not. Coult be that an option? WSL is not a separate distro. It's just an image like any other appliance or container. As such identical binary rpms are used. Macros in the spec file are build time options though, so not a solution. I wrote a blog post showing how yast2 firstboot is used in WSL. https://lizards.opensuse.org/2019/11/21/using-yast-firstboot-wizard-in-wsl/ From what I gather in this bug report the concern wrt reducing deps is mostly installation-images. I'll check that. Looks like it's time to split a yast2-firstboot subpackage with different dependencies off yast2-installation. While it may be true that many of the required packages are not needed for the firstboot stage, having real package dependencies to build installation-images is much superior and much less fragile than a handcrafted list in some obscure file that we had many years ago. There already is yast2-firstboot but it requires yast2-installation as it uses modules from it. Hardcoding those deps in the spec file isn't fully correct either since the control file determines what modules are used. So in an ideal world the instsys would have to be built based on the control.xml. But then the inst-sys is meant to generic enough to support all kinds of custom contol.xml so in the end you have to pull in everything anyways. At that point it doesn't really matter if a pr to yast2-installation or installation-images, or some other package that keeps install deps is needed. Anyways, I can't get far with this anyways as eg yast2-network is needed by yast2-ldap which is needed by yast2-users which of course is needed to create users. So overall the yast deps are not fine grained enough yet for less generic installations. So short of that another option might be to put tags in desktop files to avoid showing modules we know won't work. I'll close the bug at this point as no concrete action can be done by the yast team right now I think. I may still submit some smaller changes referring to it. |