[yast-devel] requires in yast packages
Hi,
This is a question to the old YaST hackers:
I heard the rumor that there once was a policy that YaST packages should
not require other (non-YaST) packages directy but rather do a check at
runtime if everything is there and ask to install packages if missing.
There are valid use cases for this where I can see that this makes
sense, eg. you configure the user authentication method LDAP and
pam_ldap is missing. It does not make sense to include pam_ldap then in
some YaST package because it is required due to a configuration
setting.
My question relates to yast2-x11 where the first action of the module
is, to check if its required packages are there.
IMHO these packages should be required by the package directly.
Btw. packages that do not exist at all are filtered out of this list.
If these packages for some reason are not available for the current
architecture or system then this very YaST module should not have been
installed in the first place.
So my question (finally) is:
Are there any technical reasons (and what exactly) why we used to do it
this way over the years or will it hurt anybody if I require the needed
packages directly??
Thanks for your comments.
(even if it reads: Why do you ask, just fix it!)
Ciao,
Daniel
--
J. Daniel Schmidt
* J. Daniel Schmidt
Hi,
This is a question to the old YaST hackers:
I heard the rumor that there once was a policy that YaST packages should not require other (non-YaST) packages directy but rather do a check at runtime if everything is there and ask to install packages if missing.
Its not a rumor, its a fact ;-)
There are valid use cases for this where I can see that this makes sense, eg. you configure the user authentication method LDAP and pam_ldap is missing. It does not make sense to include pam_ldap then in some YaST package because it is required due to a configuration setting.
My question relates to yast2-x11 where the first action of the module is, to check if its required packages are there. IMHO these packages should be required by the package directly. Btw. packages that do not exist at all are filtered out of this list.
If these packages for some reason are not available for the current architecture or system then this very YaST module should not have been installed in the first place.
Not quite. The rule is: YaST should be there, even in a minimal installation, to guide the user. The use case is: User does a minimal, textmode installation. Maybe because of limited bandwidth, maybe because its a headless (without graphics card) server. Now he wants to configure X11. YaST is there to help and on starting yast2-x11, the user is prompted to install missing packages. Now the question is: Should a YaST module do the test for missing packages at every start ? I'd say no ! This test should only be done at first start. If there's already a configuration (e.g. for X11), the YaST module should assume all packages are installed and user wants a reconfiguration only. Testing for missing packages should be optional (e.g. via menu item or button) in this case.
So my question (finally) is: Are there any technical reasons (and what exactly) why we used to do it this way over the years or will it hurt anybody if I require the needed packages directly??
Its not technical, its more product management ;-) Hth, Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Thanks for your quick answer, Klaus, On Thursday 06 November 2008, Klaus Kaempf wrote:
Not quite. The rule is: YaST should be there, even in a minimal installation, to guide the user.
With "YaST should be there" meaning: "all modules that we declare useful should be installed by default"?
The use case is: User does a minimal, textmode installation. Maybe because of limited bandwidth, maybe because its a headless (without graphics card) server. Now he wants to configure X11. YaST is there to help and on starting yast2-x11, the user is prompted to install missing packages.
Ok, got the idea. From my point of view the usecase is (slightly different): User does a minimal installation, because of ...xy... and this minimal installation does not include yast2-x11 (nor its requirements). Now he wants to configure X11 and therefore installs the needed packages which automatically pull in all requirements. But I see that it makes things uncomfortable for eg. the unexperienced user who did a minimal installation and now wants to configure X11 but can not find anything to start with. I think we should discuss this issue again later when we have a solution like the following consistent and working in our distribution(s): http://kobliha-suse.blogspot.com/2008/08/yast-can-list-not-yet-installed-mod...
Now the question is: Should a YaST module do the test for missing packages at every start ? I'd say no !
I'd say yes :)
This test should only be done at first start. If there's already a configuration (e.g. for X11), the YaST module should assume all packages are installed and user wants a reconfiguration only.
Assuming, that something is there creates lots of funny errors that are not fun to debug! Testing for missing packages only on the first start is a good thing, sure, but the package manager will not warn the user when he after the first usage removes a package that is needed by a YaST module that manages its dependencies in this way. Nor will the package manager tell you that there might be a version conflict if you up- or downgrade a required package that gets incompatible by this.
Testing for missing packages should be optional (e.g. via menu item or button) in this case.
If not required by the package itself (so the user gets a warning if he accidentally or knowingly tries to remove it) it should be default.
Its not technical, its more product management ;-)
Ok, so we solved a product management requirement by not using the best
technology we have to handle technical requirements ;-)
So, I will not change anything for now but I am still of the opinion
that we should fix this in the future. Lukas presented a very neat way
of solving this.
Ciao,
Daniel
--
J. Daniel Schmidt
participants (2)
-
J. Daniel Schmidt
-
Klaus Kaempf