Actually installed packages

Actually installed packages

[William Delacre]

Hi,

What’s the difference between the build/buildhistory/packages content (all
the packages found here) and the installed-packages.txt file in
/buildhistory/images/...... ?

I can see packages in first one which are not included in
installed-packages.txt

Could anyone explain this to me ?
Thanks :-)

Re: Actually installed packages

[Max Krummenacher]

Hi

> What’s the difference between the build/buildhistory/packages content (all
> the packages found here) and the installed-packages.txt file in
> /buildhistory/images/...... ?
> 
> I can see packages in first one which are not included in
> installed-packages.txt

A recipe can provide several packages, usually one with the same
name as the recipe name, then the -dev, -dbg, -doc ... packages,
but a lot of recipes provide additional packages.

An image recipe defines what packages need to be installed in an
image.

Even if your image requires only a part of the packages that a
recipe provides, all packages will be built and will be visible
in build/buildhistory/packages leading to what you describe above.

On top of that, if you built an image which contains different
packages before or bitbaked single recipes then those would also
be seen in the build/buildhistory/packages tree.

Max

Re: Actually installed packages

[William Delacre]

Le sam. 4 août 2018 à 00:12, Max Krummenacher <max.oss.09@gmail.com> a
écrit :

> Hi
>
> > What’s the difference between the build/buildhistory/packages content
> (all
> > the packages found here) and the installed-packages.txt file in
> > /buildhistory/images/...... ?
> >
> > I can see packages in first one which are not included in
> > installed-packages.txt
>
> A recipe can provide several packages, usually one with the same
> name as the recipe name, then the -dev, -dbg, -doc ... packages,
> but a lot of recipes provide additional packages.
>
> An image recipe defines what packages need to be installed in an
> image.
>
> Even if your image requires only a part of the packages that a
> recipe provides, all packages will be built and will be visible
> in build/buildhistory/packages leading to what you describe above.
>
> On top of that, if you built an image which contains different
> packages before or bitbaked single recipes then those would also
> be seen in the build/buildhistory/packages tree.
>
> Max


That’s really clear ! All I needed ! Thanks a lot :-)

>
>
>

Re: Actually installed packages

[William Delacre]

Sorry, I just have a last question about those packages.
In bitbake.conf, you can find this :

PACKAGE_BEFORE_PN ?= ""
PACKAGES = "${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale
${PACKAGE_BEFORE_PN} ${PN}"

This means that all those packages (whatever the recipe is) will be
automatically installed if the PACKAGES variable is not redefined in the
recipe (so if '=' is used and not '+=' or *append) *So if I don't want
those packages for one of my software/library, I have to explicitely
specify it in the recipe ?

Thanks :-)

William

Le sam. 4 août 2018 à 14:12, William Delacre <williamdelacre@gmail.com> a
écrit :

>
>
> Le sam. 4 août 2018 à 00:12, Max Krummenacher <max.oss.09@gmail.com> a
> écrit :
>
>> Hi
>>
>> > What’s the difference between the build/buildhistory/packages content
>> (all
>> > the packages found here) and the installed-packages.txt file in
>> > /buildhistory/images/...... ?
>> >
>> > I can see packages in first one which are not included in
>> > installed-packages.txt
>>
>> A recipe can provide several packages, usually one with the same
>> name as the recipe name, then the -dev, -dbg, -doc ... packages,
>> but a lot of recipes provide additional packages.
>>
>> An image recipe defines what packages need to be installed in an
>> image.
>>
>> Even if your image requires only a part of the packages that a
>> recipe provides, all packages will be built and will be visible
>> in build/buildhistory/packages leading to what you describe above.
>>
>> On top of that, if you built an image which contains different
>> packages before or bitbaked single recipes then those would also
>> be seen in the build/buildhistory/packages tree.
>>
>> Max
>
>
> That’s really clear ! All I needed ! Thanks a lot :-)
>
>>
>>
>>

Re: Actually installed packages

[Max Krummenacher]

Hi

> Sorry, I just have a last question about those packages.
> In bitbake.conf, you can find this :
> 
> PACKAGE_BEFORE_PN ?= ""
> PACKAGES = "${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale
> ${PACKAGE_BEFORE_PN} ${PN}"
> 

This is the default list of packages which together with the
corresponding FILES_* variables define what packages with what
content get created.

See also the following links into the documentation:
https://www.yoctoproject.org/docs/2.5/mega-manual/mega-manual.html#new-recipe-packaging
https://www.yoctoproject.org/docs/2.5/mega-manual/mega-manual.html#splitting-an-application-into-mul
tiple-packages

> This means that all those packages (whatever the recipe is) will be
> automatically installed

No, that is plain wrong. The packages will get created but if they get
installed or not is up to the image recipe you are building.

Packages get installed because they are listed in IMAGE_INSTALL
variable of the image recipe or they are RDEPENDS, RRECOMMENDS of
a package which gets installed.

>  if the PACKAGES variable is not redefined in the
> recipe (so if '=' is used and not '+=' or *append) *So if I don't want
> those packages for one of my software/library, I have to explicitely
> specify it in the recipe ?

I guess that is the wrong question, yes if you don't want a specific
package you would need to not have it in the PACKAGES variable. 
I think though that I've seen strange things happening when not
having the defaults (-dbg, -dev, ...) though.

However, 

if your install task installs files which you do not want in any package,
then you rather should delete those files before packaging them, i.e.:
do_install_append () { rm -f ${D}/usr/bin/not_to_be_distributed }

if the defaults package files into the wrong package then mess with the
FILES_* variable.

Max