Mailinglist Archive: yast-devel (73 mails)

< Previous Next >
Re: [yast-devel] yast Mode.* variables
On 07/22/2014 01:13 PM, Steffen Winterfeldt wrote:
On Tue, 22 Jul 2014, Jiri Srain wrote:

I think that we need that many modes. Just look at the control file,
you will find different workflow for most of them and the mode is
there to select the right one. Therefore, when AutoYaST upgrade (with
a new work-flow) was introduced, it was needed to also introduce a new
mode. And I think that the same will happen if another kind of
work-flow is introduced.

One thing about the Mode vraiable is that it mixes different things. There
(a) are kinds of workflows:


and (b) flags, modifying workflows:


The first group's modes are basically mutually exclusive if I understand
correctly (wew workflow -> new mode). Then this should be reflected in
the code.
So instead we should have something like

context = autoinst|autoupgrade|...

Then there's only 7 cases to deal with instead of 2^7. You can always
a wrapper object for convenience. Like or context.install?.

There is a single variable which stores the mode. All the rest are just wrappers comparing this variable to a particular value (or values). Therefore you definitely cannot have 2^7 modes. (*)

The confusion here is IMO the result of conversion from YCP; if the code used ruby naming conventions, Mode.update would definitely be called Mode.update?

# we're doing an update
def update
mode == "update" || mode == "autoupgrade"

(*) OK, there is one variable for general mode, one variable for testing mode (which should IMO be squeezed out as a next step after switch to Ruby) and one variable for UI mode - but still not 3^7 different modes :-)



Jiri Srain
Project Manager
SUSE LINUX, s.r.o. e-mail: jsrain@xxxxxxxx
Lihovarska 1060/12 tel: +420 284 084 659
190 00 Praha 9 fax: +420 284 084 001
Czech Republic
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: yast-devel+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups