Mailinglist Archive: zypp-devel (115 mails)
| < Previous | Next > |
[zypp-devel] Re: Init of ZYpp configuration and root
- From: Michael Andres <ma@xxxxxxx>
- Date: Mon, 2 Jul 2007 14:58:01 +0200
- Message-id: <20070702125801.GA16667@xxxxxxx>
On Sun, Jul 01, Duncan Mac-Vicar P. wrote:
>
> Hi
>
> We have to think about the sequence and layers of configuration to make it
> consistent this time.
>
> I list the requirements that come to my mind
>
> - the most important cfg option is the root where you are operating on. In
> former times this was a Target option, and I think it still is (????)
>
> - known repositories raw metadata path, binary cache path, system
> architecture, etc, needs to be easily configurable/overridable. A zypp.conf
> file (ini file) would be a nice way to do it.
>
> So we have to determine the workflow:
>
> - when to set the target root
> - when do we read values from the config file
Let's create a class that grants access to all these config values. An
Instance of this class is passed to ZYpp upon construction.
ZYpp and it's subcomponents have to be adapted to take all config values
from this context class, and use them to initialize their's subcomponents.
That way e.g. ZYpp::targetInit would loose it's 'root' argument. Zypp will
use the argument provided by the context class instead. That's probabely
the most significant change, because zypper/pkg-bindings have to tell the
root path quite early in their workflow (before accessing ZYpp).
Then everything depends on the implementation of the context class only.
A bare metal installation or some faked Test environment might use an
implementation where most/all of the values are set by the application.
Another kind of implementation might take the target root (default to
/) and an optional config file, and initializes the config values lazy
by parsing the configuration file.
As long as the class behaves correctly, no one will mind where the values
come from.
(Un)fortunately all our code (libzypp,zypper,pkg-bindings,UI) refers to
some global ZYpp singleton, that's construced on demand. I don't think we
wan't to change this now.
But we could pass an instance of this context class to the ZYppFactory,
and ZYppFactory will use it to construct ZYpp.
--
cu,
Michael Andres
+------------------------------------------------------------------+
Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4
+------------------------------------------------------------------+
Michael Andres YaST Development ma@xxxxxxxxxx
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)
Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 740 53-0
+------------------------------------------------------------------+
--
To unsubscribe, e-mail: zypp-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: zypp-devel+help@xxxxxxxxxxxx
>
> Hi
>
> We have to think about the sequence and layers of configuration to make it
> consistent this time.
>
> I list the requirements that come to my mind
>
> - the most important cfg option is the root where you are operating on. In
> former times this was a Target option, and I think it still is (????)
>
> - known repositories raw metadata path, binary cache path, system
> architecture, etc, needs to be easily configurable/overridable. A zypp.conf
> file (ini file) would be a nice way to do it.
>
> So we have to determine the workflow:
>
> - when to set the target root
> - when do we read values from the config file
Let's create a class that grants access to all these config values. An
Instance of this class is passed to ZYpp upon construction.
ZYpp and it's subcomponents have to be adapted to take all config values
from this context class, and use them to initialize their's subcomponents.
That way e.g. ZYpp::targetInit would loose it's 'root' argument. Zypp will
use the argument provided by the context class instead. That's probabely
the most significant change, because zypper/pkg-bindings have to tell the
root path quite early in their workflow (before accessing ZYpp).
Then everything depends on the implementation of the context class only.
A bare metal installation or some faked Test environment might use an
implementation where most/all of the values are set by the application.
Another kind of implementation might take the target root (default to
/) and an optional config file, and initializes the config values lazy
by parsing the configuration file.
As long as the class behaves correctly, no one will mind where the values
come from.
(Un)fortunately all our code (libzypp,zypper,pkg-bindings,UI) refers to
some global ZYpp singleton, that's construced on demand. I don't think we
wan't to change this now.
But we could pass an instance of this context class to the ZYppFactory,
and ZYppFactory will use it to construct ZYpp.
--
cu,
Michael Andres
+------------------------------------------------------------------+
Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4
+------------------------------------------------------------------+
Michael Andres YaST Development ma@xxxxxxxxxx
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)
Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 740 53-0
+------------------------------------------------------------------+
--
To unsubscribe, e-mail: zypp-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: zypp-devel+help@xxxxxxxxxxxx
| < Previous | Next > |