Package Level Dependencies

Package Level Dependencies

[sebastian.rohde]

Hi,

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".

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.

Help ist strongly appreciated.

Regards,
Sebastian Rohde
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.

Re: Package Level Dependencies

[Rudolf J Streif]

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

Re: Package Level Dependencies

[sebastian.rohde]

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?

Regards,
Sebastian

-----Ursprüngliche Nachricht-----
Von: Rudolf J Streif [mailto:rudolf.streif@gmail.com]
Gesendet: Montag, 22. Februar 2016 02:38
An: yocto@yoctoproject.org
Cc: Rohde, Sebastian <sebastian.rohde@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.

Re: Package Level Dependencies

[Philip Balister]

On 02/22/2016 08:00 AM, sebastian.rohde@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.streif@gmail.com]
> Gesendet: Montag, 22. Februar 2016 02:38
> An: yocto@yoctoproject.org
> Cc: Rohde, Sebastian <sebastian.rohde@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.
> 

Re: Package Level Dependencies

[Rudolf J Streif]

Hi Sebastian,

> 
> 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.
> 
Well, that wouldn't solve the problem of having 10 to 20 different recipes 
either, since you would have to write a recipe for each config file with a 
specific PROVIDES in it.


> 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?
>
I suppose you are talking about a remote Git repository. The do_fetch task 
will first check it out locally to DL_DIR. If all of your config recipes use the 
same URL for the source BitBake would only check it out once locally to 
DL_DIR. That automatically saves the download step. However, for each recipe 
the do_unpack task would copy the config sources from DL_DIR to ${S}. You could 
skip do_unpack and point ${S} to a different directory, but that is getting 
rather messy. I would not recommend it.

Essentially, what approach to take comes actually down to what the criteria 
are to select one configuration file over the other. What is it dependent on 
that you select test123-config-XXX rather than test123-config-YYY?

If it is a build-time dependency such as the MACHINE then you can do a 
conditional override, as Philipp Ballister suggested.

If it is a build configuration dependency you could resolve it in the install 
task. Maybe you could define your own configuration variable that you set in 
local.conf (or in a disto configuration file):

TEST123_CONFIG = "XXX"

Recipe:

do_install_append () {
    # install config file here
    install 544 test123-${TEST123_CONFIG}.conf ${D}/<location>
}

Cheers,
Rudi