packages versioning

packages versioning

[Mr Dash Four]

Is there a way I could force/select a particular version of a specific 
package in a given target?

I am building my fso-console-image and I would like it to use udev-165 
instead of udev-162, but I can't find a way to alter this. I could build 
udev-165 separately - no problem, but don't know how to integrate this 
into the main task of building the image itself.

Also, is there a way I can include additional packages as part of that 
fso-console-image build? I'd like to have openvpn, a different version 
of wpa_supplicant, openssl etc.

Re: packages versioning

[Chris Larson]

On Thu, Dec 8, 2011 at 7:57 PM, Mr Dash Four
<mr.dash.four@googlemail.com> wrote:
> Is there a way I could force/select a particular version of a specific
> package in a given target?
>
> I am building my fso-console-image and I would like it to use udev-165
> instead of udev-162, but I can't find a way to alter this. I could build
> udev-165 separately - no problem, but don't know how to integrate this into
> the main task of building the image itself.

PREFERRED_VERSION_udev = "165"

> Also, is there a way I can include additional packages as part of that
> fso-console-image build? I'd like to have openvpn, a different version of
> wpa_supplicant, openssl etc.

IMAGE_INSTALL_append = " openvpn"

-- Christopher Larson

Re: packages versioning

[Mr Dash Four]

>> Is there a way I could force/select a particular version of a specific
>> package in a given target?
>>
>> I am building my fso-console-image and I would like it to use udev-165
>> instead of udev-162, but I can't find a way to alter this. I could build
>> udev-165 separately - no problem, but don't know how to integrate this into
>> the main task of building the image itself.
>>     
>
> PREFERRED_VERSION_udev = "165"
>
>   
>> Also, is there a way I can include additional packages as part of that
>> fso-console-image build? I'd like to have openvpn, a different version of
>> wpa_supplicant, openssl etc.
>>     
>
> IMAGE_INSTALL_append = " openvpn"
>   
Superb, thank you! One more query regarding this - how do I remove 
packages I do not want included in the final image? Is there a way to do 
that (fairly) easily?

Re: packages versioning

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Op 09-12-11 13:59, Mr Dash Four schreef:
> 
>>> Is there a way I could force/select a particular version of a
>>> specific package in a given target?
>>> 
>>> I am building my fso-console-image and I would like it to use
>>> udev-165 instead of udev-162, but I can't find a way to alter this. I
>>> could build udev-165 separately - no problem, but don't know how to
>>> integrate this into the main task of building the image itself.
>>> 
>> 
>> PREFERRED_VERSION_udev = "165"
>> 
>> 
>>> Also, is there a way I can include additional packages as part of
>>> that fso-console-image build? I'd like to have openvpn, a different
>>> version of wpa_supplicant, openssl etc.
>>> 
>> 
>> IMAGE_INSTALL_append = " openvpn"
>> 
> Superb, thank you! One more query regarding this - how do I remove
> packages I do not want included in the final image? Is there a way to do
> that (fairly) easily?

Yes, create your own image recipe.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAk7iDqoACgkQMkyGM64RGpE03wCfcIs3EgRCInV/7UR4HHhslFZN
57kAoKbY+qE+wCxTLMQbEczLYiSr+a+u
=4Wsq
-----END PGP SIGNATURE-----

Re: packages versioning

[Mr Dash Four]

>> One more query regarding this - how do I remove
>> packages I do not want included in the final image? Is there a way to do
>> that (fairly) easily?
>>     
>
> Yes, create your own image recipe.
>   
I was hoping that there is an easier option ("(fairly) easily" being the 
keywords here)!

I tried to trace where these packages are derived from, but could not 
find anything. For example, I'd like to remove ash (and possibly the 
whole BusyBox setup) and replace it with bash and their package 
equivalents. By looking at the tasks/ as well as images/ directories I 
couldn't find where these packages are derived from, hence the above 
question.

Re: packages versioning

[Mark Hatle]

On 12/9/11 9:59 AM, Mr Dash Four wrote:
>
>>> One more query regarding this - how do I remove
>>> packages I do not want included in the final image? Is there a way to do
>>> that (fairly) easily?
>>>
>>
>> Yes, create your own image recipe.
>>
> I was hoping that there is an easier option ("(fairly) easily" being the
> keywords here)!
>
> I tried to trace where these packages are derived from, but could not
> find anything. For example, I'd like to remove ash (and possibly the
> whole BusyBox setup) and replace it with bash and their package
> equivalents. By looking at the tasks/ as well as images/ directories I
> couldn't find where these packages are derived from, hence the above
> question.

The creation of the filesystem image is driven by a number of components. 
Basically it works like this:

You select an image to build.  The image sets a few flags and a basic set of 
requirements.  The image inherits the core-image.bbclass.

The core-image.bbclass uses the flags, machine settings and extra settings to 
determine a list of actual dependencies.  Most of these dependencies are broken 
into groups.  Some of the groups are individual sets of recipes, while most are 
actually tasks.

The tasks themselves are broken down into functional areas.  These functional 
areas are designed to give you control at a "functional" level, designed to 
assist people who really aren't sure exactly what source packages to start from. 
  If you look for a list of the tasks you can see the breakdown and components.

In the recipes-extended, there is a set of core-tasks.  These tasks allow you to 
build up a system starting with busybox, and slowly add to it and replace 
busybox with the discrete components from util-linux, coreutils, etc.

I have a spreadsheet (OpenOffice 17k, or Excel 81k) that lists all of the 
current breakdowns.  If you are interested send me an email off list.

--Mark

Re: packages versioning

[Mr Dash Four]

> The creation of the filesystem image is driven by a number of 
> components. Basically it works like this:
Thanks a lot for that - a good insight into the workings of oe and 
bitbake. I was hoping there would be an easier way to configure/change 
this to what I want, but I see that it is much more complex than I 
thought initially.

> I have a spreadsheet (OpenOffice 17k, or Excel 81k) that lists all of 
> the current breakdowns.  If you are interested send me an email off list.
I am interested (excel would be nice, thanks), but don't know your email 
address (all I get when responding to 'all' is the mailing list email 
address) - if you know mine, you could send me that and I'll have a look.

I take it there isn't an easy way to see the hierarchy of all 
packages/dependencies involved in a particular image, is it (your 
spreadsheet may be good, but I suppose it is static and reflects just a 
current snapshot of a given packages/dependencies and that might change)?

If all else fails, I might use ipkg on the target system to uninstall 
the packages I don't need and install new ones - not ideal by any means, 
but this is what I'll do only as a last resort, if all else fails. 
Thanks again for the thorough response!

Re: packages versioning

[Gary Thomas]

On 2011-12-09 11:57, Mr Dash Four wrote:
>
>> The creation of the filesystem image is driven by a number of components. Basically it works like this:
> Thanks a lot for that - a good insight into the workings of oe and bitbake. I was hoping there would be an easier way to configure/change this to what I want, but I see that it is
> much more complex than I thought initially.
>
>> I have a spreadsheet (OpenOffice 17k, or Excel 81k) that lists all of the current breakdowns. If you are interested send me an email off list.
> I am interested (excel would be nice, thanks), but don't know your email address (all I get when responding to 'all' is the mailing list email address) - if you know mine, you
> could send me that and I'll have a look.
>
> I take it there isn't an easy way to see the hierarchy of all packages/dependencies involved in a particular image, is it (your spreadsheet may be good, but I suppose it is static
> and reflects just a current snapshot of a given packages/dependencies and that might change)?
>
> If all else fails, I might use ipkg on the target system to uninstall the packages I don't need and install new ones - not ideal by any means, but this is what I'll do only as a
> last resort, if all else fails. Thanks again for the thorough response!

You can also use 'bitbake -u hob' which will let you interactively
build and modify images.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: packages versioning

[Mark Hatle]

On 12/9/11 12:57 PM, Mr Dash Four wrote:
>
>> The creation of the filesystem image is driven by a number of
>> components. Basically it works like this:
> Thanks a lot for that - a good insight into the workings of oe and
> bitbake. I was hoping there would be an easier way to configure/change
> this to what I want, but I see that it is much more complex than I
> thought initially.

Ya, I created the spreadsheet due to the complexity.. :(  I like the flexibility 
of the components that are used to construct the image packages, but there has 
to be a more transparent way of doing this.

>> I have a spreadsheet (OpenOffice 17k, or Excel 81k) that lists all of
>> the current breakdowns.  If you are interested send me an email off list.
> I am interested (excel would be nice, thanks), but don't know your email
> address (all I get when responding to 'all' is the mailing list email
> address) - if you know mine, you could send me that and I'll have a look.

(Sent as a private email)

> I take it there isn't an easy way to see the hierarchy of all
> packages/dependencies involved in a particular image, is it (your
> spreadsheet may be good, but I suppose it is static and reflects just a
> current snapshot of a given packages/dependencies and that might change)?
>
> If all else fails, I might use ipkg on the target system to uninstall
> the packages I don't need and install new ones - not ideal by any means,
> but this is what I'll do only as a last resort, if all else fails.
> Thanks again for the thorough response!

As Gary suggested in another email, "hob" is the best approach right now.

You can certainly remove binary packages after the fact, but it's much nicer to 
not have to.

--Mark

Re: packages versioning

[Mr Dash Four]

> Ya, I created the spreadsheet due to the complexity.. :(  I like the 
> flexibility of the components that are used to construct the image 
> packages, but there has to be a more transparent way of doing this.
I concur. I am starting to like oe and its flexibility, but it is a hell 
of a steep curve at first to take on...particularly for people like me 
that have little-to-no experience of oe.

> (Sent as a private email)
Got it, thanks a lot - will look at it tomorrow in more detail.

> As Gary suggested in another email, "hob" is the best approach right now.
I'll try that as well - it would be nice to see where all these 
dependencies/packages come from, because for my (admittedly, rather 
limited) case I won't need half the packages installed on that image, 
but OTOH would need to add a few additions of my own to what is already 
'included', so it is quite a change. I also plan to create one or two 
new recipes for packages worth including (particularly for small systems 
like the console image I am trying to build).

What is the policy of submitting patches on here - I followed the debate 
about oe-classic/oe-core, but am still unclear if I want to submit 
patches (I am working with oe-classic - so I am told) what should I base 
against these?

> You can certainly remove binary packages after the fact, but it's much 
> nicer to not have to.
Indeed and it is the reason for asking here first as I always believe 
there must be more intelligent and elegant solution to this than hacking 
the target system (which I'll have to do each time I 
build/update/upgrade that image).

Re: packages versioning

[Mr Dash Four]

> PREFERRED_VERSION_udev = "165"
>   
OK, hit a bit of a snag:

PREFERRED_VERSION_wpa-supplicant = "0.7.3"

but this still produces wpa-supplicant_0.6.9-r6.1.6_armv6-novfp.ipk and 
wpa-supplicant-passphrase_0.6.9-r6.1.6_armv6-novfp.ipk. The recipe for 
wpa-supplicant_0.7.3 is there, don't know why isn't used/included. Any 
ideas on what I am doing wrong?

I also found two more errors when trying to include/compile 
xtables-addons - there are two versions available in oe - 1.26 & 1.28. I 
was planning to adapt the newest one (1.28) to compile the latest 
xtables-addons, as well as be able to customise the various modules 
which are included by "default" in this recipe, though I get the 
following errors which prevent building this package and including it 
into the image:

v1.28:
~~~~
ERROR: Task do_unpack in 
/home/mr-4/oe/openembedded/recipes/xtables-addons/xtables-addons_1.28.bb 
depends upon nonexistant task do_populate_staging in 
virtual:native:/home/mr-4/oe/openembedded/recipes/xz/xz_5.0.0.bb

I first thought that there is a dependency missed for including "xz", 
but even if I include this in my local.conf I still get the above error. 
Any idea what is causing this?

v1.26:
~~~~~
arm-oe-linux-gnueabi-ld: unrecognized option '-Wl,-O1'
arm-oe-linux-gnueabi-ld: use the --help option for usage information

That, I suppose, comes from the make linker flags. I am not sure this 
should be included there (shoudn't that be just "-O1"?).