[oe] Creating Rootfs images without packages

mgundes mgcse at hotmail.com
Wed Oct 12 13:47:30 UTC 2011


On Wed, Oct 12, 2011 at 4:21 PM, Gary Thomas <gary at mlbassoc.com> wrote:

> On 2011-10-12 07:10, mgundes wrote:
>
>
>>
>> On Wed, Oct 12, 2011 at 3:34 PM, Gary Thomas <gary at mlbassoc.com <mailto:
>> gary at mlbassoc.com>> wrote:
>>
>>    On 2011-10-12 06:22, mgundes wrote:
>>
>>            Hi,
>>
>>            I think one of the big issue with OE is build time. It does
>> everything
>>        for you, so that it takes too much times. I want to minimize build
>> time and
>>        realized that OE creates ipkgs for almost every package. If there
>> is a way
>>
>>
>>    Not true.  Only the packages needed to complete your image will be
>> built.
>>
>>    That said, there are some packages which are built (the first time
>> only) that
>>    comprise the build environment and tool chain which takes a lot of
>> time, but
>>    this is only the first time through.
>>
>>    What image & target are you building for and what packages are built
>> that you
>>    don't think needed to be built?
>>
>>
>>
>>      In my tmp/work directroy there are 868 ipk packages which was created
>> by OE:
>>
>> $ find -iname *.ipk | wc -l
>> 868
>>
>
> You'll find nearly 1/2 of those are support packages, e.g. XXX-dbg or
> XXX-dev, which are only
> used for development or debugging and not normally installed on your image.
>
>
>
>>      I use arm based pc7302 chipset and vendor supplied machine and distro
>> configuration. I use standard filesystem with packages like below in my
>> rootfs image.
>>
>> IMAGE_INSTALL += "base-files base-files-doc  base-passwd  busybox  bash
>>  mtd-utils  dropbear  ethtool  firmwareupdate  strace  oprofile
>>  kernel-modules  memview \
>>                                 modutils-initscripts modutils pareadback
>> picomon2 picoifapp picofuse ubootenv"
>>
>>      Of course every needed packages should be built and located into
>> rootfs filesystem directory.
>>
>> "ipk" and "deb" files are used to install target system, right? I mean If
>> I don't need ipkgs as a developer, it would be nice if there is a way to
>> prevent ipkg creation steps. As
>> far as I know, OE creates ipk from built package's files and then use
>> created ipks to create rootfs directory; then creates image from rootfs
>> directory. I am asking that what about
>> directly creating a rootfs directory and install built package files to
>> rootfs after compilation in install tasks. By this way there is no need to
>> create ipkgs? Am I right?
>>
>
> That's not the OE philosophy.  Using ipkg (or rpm) is a way of keeping the
> relevant files
> in a convenient, reusable, container.  These containers are then used to
> build the image.
> By having reusable containers, you can [re]use the same set to build
> multiple different images
> without having to rebuild the component pieces.  Also, the working
> directories used to
> build the packages can be purged after the package containers have been
> created.
>
>
>
      That's good if you build more than one types of images and this is why
not good for me because I use OE for just one type of image. At that point,
you are right. However I think OE developers can consider this issue since
there may be many people use OE for just one type of image.


>
>>        to prevent creation of ipkgs it would be really good for me. In my
>> opinion,
>>        it would be fine for other people too since usually rootfs
>> directory is
>>        enough and ipkgs are not frequently used directly by developers.
>>
>>            I have asked in freenode oe room but friends said there no way
>> to do that
>>        in OE system. If there is no way to do that in current OE, do you
>> plan to
>>        add as a feature?
>>
>
>
> --
> ------------------------------**------------------------------
> Gary Thomas                 |  Consulting for the
> MLB Associates              |    Embedded world
> ------------------------------**------------------------------
>
>
Thanks,
Regards,

-- 
MahmutG



More information about the Openembedded-devel mailing list