[Libosinfo] [PATCHv4 06/11] Add OsinfoInstallConfig:config-params property

Christophe Fergeau cfergeau at redhat.com
Tue Dec 18 17:38:24 UTC 2012


On Tue, Dec 18, 2012 at 07:18:04PM +0200, Zeeshan Ali (Khattak) wrote:
> On Tue, Dec 18, 2012 at 6:43 PM, Christophe Fergeau <cfergeau at redhat.com> wrote:
> > In my opinion, the second approach is more convenient both for the library
> > user and for us from a maintainance point of view, which explains my
> > insistance on moving this way ;)
> 
> Thanks for the summary. Thing is that we have already moved a lot
> towards the first approach

Are you saying the OsinfoInstallScript/OsinfoInstallConfig/
OsinfoInstallConfigParam relationship was intentionally designed this way?
Ie OsinfoInstallConfigParam and OsinfoInstallConfig are separate on
purpose? Until now my feeling was that this ended up being implemented
this way, but that this was not a conscious decision, especially as this
code didn't land very long ago.

> and to be able to move towards the second
> approach, we must deprecate the API that are designed for the first
> (existing) approach. Otherwise we'll just be confusing app developers
> with this contradiction.

I'm not exactly sure what API you have in mind exactly. All I'm suggesting
is gradual improvement and having a clear idea of what belongs where. I
don't think we have things to deprecate to achieve that.

> While I might agree with you that the 2nd approach is better, I don't
> think its worth it to change towards that now.

Once again, I'm a bit confused what there is to change here, nor where the
big changes are. The only change I'm suggesting is having an (optional)
OsinfoInstallConfigParamList be part of OsinfoInstallConfig, and use that
if we later need parameter validation, ... This also means recommending the
use of osinfo_install_config_new_for_script(), but even using that new
method is not required, things will still work fine when using
osinfo_install_config_new().

Please be more concrete as to why this is such an invasive unwanted change.

Christophe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libosinfo/attachments/20121218/764187a4/attachment.sig>


More information about the Libosinfo mailing list