Hello Jean,
... forwarding to oscar-devel ...
On Friday 09 November 2007 11:47, Jean Parpaillon wrote:
> > I still need a change: I would like to be able to install the opkg-API rpms
> > no matter whether they have conflicts or not, because I would like to have
> > them around and the information they are carrying. But this means that
> > conflicts, requires and provides need to be treaded specially in opkg-API.
> > A simple idea is to make OPKG relations distinguishable from RPM relations.
> >
> >
> Are you sure you need to install a package to know what it does ?
> You can extract (almost) everything from a package without installing it:
> rpm -qp --qf "%{Requires}" file.rpm
We need to install the opkg-API packages anyway at some stage. This is
equivalent
to distributing the packges in the OSCAR tree (as done before) or with
downloading opkgs with OPD (also history). Also: having the packages available
(and installed) means: you have their setup scripts, and those must be exectuted
very early. Having them installed simplifies very much the querying process:
you talk to one single database instead of the many separate rpm files (which,
by the way, may be on remote repositories).
> > We need to deal with meta-capabilities, for example opkg-lam and opkg-mpich
> > both provide a capability called "mpi". This could be expressed in the
> > Provides: field of any opkg-*-*
> >
> Ok. This can already be done in opkg: field "Provides" exists.
> > We need to deal with real opkg conflicts (one opkg doesn't like another opkg
> > to be around). This needs to be expressed in a way that does not hinder us
> > to install any opkg-API, but will show up as real conflict among
> > opkg-*-client/server rpms. Normally conflicts will deal with opkg names,
> > never
> > with meta-capabilities.
> >
> > And we need to deal with real package (rpm) requires, this is done and
> > should
> > stay as it is.
> >
> > This could mean:
> >
> > 1) for opkg-NAME
> > Provides: OPKGMETA(batch) # a meta-capability
> > Provides: opkg-NAME # provides itself, is present by default
> > Requires: opkg-ganglia # a real requirement for another opkg-API
> > Requires: OPKGMETA(blah) # a meta-capability requirement
> > Conflicts: OPKG:lam # conflict with lam opkg, but won't find it
> > # even if opkg-lam is installed
> >
> > 2) for opkg-NAME-client
> > Provides: opkg-NAME-client # itself, this is there by default
> > Requires: opkg-ganglia-client # requires a concrete other client opkg
> > Conflicts: opkg-lam-client # conflicts a concrete other client opkg
> >
> > Same for opkg-NAME-server
> >
> >
> > We cannot express meta-capabilities requirements on client/server opkgs,
> > they
> > would be fulfilled by the API opkgs (for the server). But the
> > meta-capabilities
> > can be used for helping the selector to do a good job.
> >
> > In fact, I think the OPKGMETA is currently a "nice to have" feature. The
> > conflicts and their difference to be expressed in opkg-API and
> > opkg-*-client/server is a more important feature, which we need quite
> > quickly.
> >
>
> "OPKGMETA" feature can already be done by defining some "virtual
> package", e.g. packages which does not exist but are "provided" by other
> packages. For instance, oscar-mpi, provided by opkg-lam, opkg-mpich, etc.
> The only thing to do is maybe to document this and to write somewhere
> the list of virtual packages.
Okay, this is a good idea. We just need a convention.
Let's call it (as you suggest): oscar-<FEATURE>
(FEATURE can not be "base" ;)
oscar-<FEATURE> can only appear in Requires: and Provides: , but not in
Conflicts:. This solves the problem.
Do we need to filter out the oscar-<FEATURE> things from the
Requires:/Provides: of the -client and -server packages?
Is there a risk that requirements for meta-capabilities are resolved
wrongly when -client/server packages are involved?
So now this makes it the following suggested rules:
1) for opkg-NAME
Provides: oscar-<FEATURE> # a meta-capability
Provides: opkg-<NAME> # provides itself, is present by default
Requires: opkg-ganglia # a real requirement for another opkg-API
Requires: oscar-blah # a meta-capability requirement
Conflicts: OPKG:lam # conflict with lam opkg, but won't result in
# real install conflicts, as nobody provides this.
# I.e.: opkg-lam is still installable
2) for opkg-NAME-client
Provides: opkg-NAME-client # itself, this is there by default
Requires: opkg-ganglia-client # requires a concrete other client opkg
Conflicts: opkg-lam-client # conflicts a concrete other client opkg
# translated automatically from the OPKG(lam)
# conflict which we have in the opkg-API
3) Same for opkg-NAME-server (as for -client)
The main work is in transforming these in the opkgc.
The config.xml would be (here a nonsense example):
Variant 1:
==========
<oscar>
<name>mpich</name>
...
<commonDeps>
<requires>
<pkg>mpich-oscar</pkg>
</requires>
</commonDeps>
<serverDeps/>
<clientDeps/>
<apiDeps/>
<requires>oscar-batch</requires> # a meta-capability requirement
<requires>switcher</requires> # an opkg dependency
<provides>oscar-mpi</provides> # providing a meta-capability
<conflicts>lam</conflicts> # conflicts with an opkg
</oscar>
I have taken the opkg level provides/requires/conflicts out of the specific
subcomponent dependencies. It is because these are package level. In fact
this should be equivalent to:
Variant 2:
==========
<oscar>
<name>mpich</name>
...
<commonDeps>
<requires>
<pkg>mpich-oscar</pkg>
<pkg>oscar-batch</pkg>
</requires>
<provides>
<pkg>oscar-mpi</pkg>
</provides>
</commonDeps>
<serverDeps>
<requires>
<pkg>opkg-switcher-server</pkg>
</requires>
<conflicts>
<pkg>opkg-lam-client</pkg>
</conflicts>
</serverDeps>
<clientDeps/>
<requires>
<pkg>opkg-switcher-client</pkg>
</requires>
<conflicts>
<pkg>opkg-lam-client</pkg>
</conflicts>
</clientDeps/>
<apiDeps>
<conflicts>
<pkg>OPKG:lam</pkg>
</conflicts>
</apiDeps>
</oscar>
Clearly, I would prefer to have to enter variant 1, it is much more easy to
understand, it has dependencies expressed at opkg level and the opkgc logic
should care about the details. opkgc would internally need to convert the
package level dependencies into different explicit subpackage level deps.
Is this doable?
Thanks & best regards,
Erich
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Oscar-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oscar-devel
