Hi,
Le 09.11.2007 13:20, Erich Focht a écrit :
> 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).
>
>
If you insist, so :-)
>>> 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:
>
> ...
>
> 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?
>
Doable, yes. Some suggestions:
1- I introduced commonDeps but it's not yet released. To avoid
multiplication of (sometime) redundant tags, I would cancel <commonDeps>
and just keep the opkg-level dependencies
2 - into the conflicts opkg-level tag, we put the complete name of the
opkg, for instance: opkg-lam. One can also want to put real conflicts at
opkg-level.
So now we have:
- For opkg-<NAME>-server and opkg-<NAME>-client, <requires>, <provides>
and <conflicts> are translated into requires, provides and conflicts at
RPM/deb level.
- For opkg-<NAME>, <conflicts> is also translated into:
- Conflicts: OPKG:<conflicts-name> for RPMs
- X-OPKG-Conflicts: <conflicts-name> for Debs (we define a
user-defined field which is accessible by any request on dpkg database).
That way, conflicts are managed by RPM/Deb systems, except for
opkg-<NAME> packages.
> Thanks & best regards,
> Erich
>
Regards,
Jean
begin:vcard fn:Jean Parpaillon n:Parpaillon;Jean org:Kerlabs;Support - Development adr:;;Campus Universitaire de Beaulieu;Rennes Cedex;;35042;France email;internet:[EMAIL PROTECTED] title:Engineer tel;work:+33 2 99 84 25 99 url:http://kerlabs.com/ version:2.1 end:vcard
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- 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
