On 02/22/2016 08:00 AM, sebastian.ro...@tu-dortmund.de wrote:
> Hi Rudolf,
> 
> Thnx for your input! I guess I can see your point. In particular I wasn't 
> thinking so much on using ".inc" files.
> Due to the fact that I will be having like 10-20 different test123-config-xxx 
> packages managing this using "RCONFLICTS" might be tedious.
> I guess this is what virtual packages (say test123-config-xxx has something 
> like PROVIDES=virtual/test123-config and test123 has a RDEPENDS on 
> virtual/test123-config) are for and I will try to follow this path for now.
> 
> For a couple of reasons, the configuration files are in the same git 
> repository as the source code of "test123". Is there a way of sharing working 
> directories between (at least all config-package recipes, such as I don't net 
> to checkout the whole git repository for each of my 10-20 config packages?

Would selecting the conf file with a MACHINE override help here?

Philip

> 
> Regards,
> Sebastian
> 
> -----Ursprüngliche Nachricht-----
> Von: Rudolf J Streif [mailto:rudolf.str...@gmail.com]
> Gesendet: Montag, 22. Februar 2016 02:38
> An: yocto@yoctoproject.org
> Cc: Rohde, Sebastian <sebastian.ro...@tu-dortmund.de>
> Betreff: Re: [yocto] Package Level Dependencies
> 
> Hi Sebastian,
> 
>> I have a recipe (say: "test123") that provides a complex piece of
>> software (cmake-based). The software needs some configuration file
>> (say "test123.conf"). There are multiple variants of the configuration
>> file, sharing the same name, i.e. "test123.conf" exists in different
>> variants for multiple hardware configurations.
>>
>> My aim would be to have multiple packages like "test123-config-XXX"
>> and "test123-config-YYY", that cannot be installed at the same time,
>> while having one of the packages is a dependency for the main package 
>> "test123".
> 
> These are two conflicting packages.
> 
>>
>> Is there a way to achieve this? From my current understanding,
>> dependencies are "per-recipe" and not "per-package". Is there any way
>> to achieve package level dependencies? I would like to avoid having
>> multiple recipes as there are many configuration file options which
>> are currently located in the same large source repository as the main 
>> software.
> 
> Look at it from the perspective of conflicting packages.
> 
> My approach to this would be the following:
> 
> 1. Write an include file test123.inc that includes all of the guts of your 
> recipe.
> 
> 2. Write the two recipes test123-config-XXX_1.0.bb and test123-config-
> YYY_1.0.bb:
> 
> test123-config-XXX_1.0.bb
> 
> require test123.inc
> 
> SRC_URI += "test123-XXX.conf"
> 
> do_install_append() {
>    # install config file here
>    install 544 test123-XXX.conf ${D}/<location> }
> 
> RCONFLICTS_${PN} = "test123-config-YYY"
> 
> Analog for test123-config-YYY_1.0.bb
> 
> 
> You are essentially sharing all of the recipe through the test123.inc and 
> only add the config file to the respective target recipe. The 
> RCONFLICTS_${PN} directive will flag an error if both conflicting packages 
> are attempted to be installed.
> 
> BR,
> Rudi
> 
> Wichtiger Hinweis: Die Information in dieser E-Mail ist vertraulich. Sie ist 
> ausschließlich für den Adressaten bestimmt. Sollten Sie nicht der für diese 
> E-Mail bestimmte Adressat sein, unterrichten Sie bitte den Absender und 
> vernichten Sie diese Mail. Vielen Dank.
> Unbeschadet der Korrespondenz per E-Mail, sind unsere Erklärungen 
> ausschließlich final rechtsverbindlich, wenn sie in herkömmlicher Schriftform 
> (mit eigenhändiger Unterschrift) oder durch Übermittlung eines solchen 
> Schriftstücks per Telefax erfolgen.
> 
> Important note: The information included in this e-mail is confidential. It 
> is solely intended for the recipient. If you are not the intended recipient 
> of this e-mail please contact the sender and delete this message. Thank you. 
> Without prejudice of e-mail correspondence, our statements are only legally 
> binding when they are made in the conventional written form (with personal 
> signature) or when such documents are sent by fax.
> 
-- 
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Reply via email to