[ELDK] Just starting - ipkg errors

[Wolfgang Denk]

Dear Larry,

In message <6275B77B-7614-4F88-9B8F-F84ABEE9FEBA at usgs.gov> you wrote:
>
> > Of course you may suggest it - but I see no reason to change the
> > current configurations.  If you have ample resources that allow for
> > such a big file system image, then just use one of the more full-blown
> > configurations - or roll your own meeting exactly your requirements.
> 
> May I suggest an alternative: do not include the package database within the rootfs
> itself, but do provide it along side the rootfs image.  The rootfs would not quite be
> self-documenting.  But, to know exactly what was installed in a rootfs image, you
> would not have to know at what commit was the git repository when the rootfs was
> created in order to find the Yocto build recipe that created it.  It can also serve as a
> validation that I can correctly recreate your rootfs -- both the rootfs images and the
> package databases should be the same.  Or, for example, that I have properly
> recreated your rootfs with updated packages, such as to apply security patches.

I think such an approch is not really attractive.  There s way too
high a risk that the actual content of the file system image and the
package database get out of sync.

No - I think what you really should do is to use the build environment
and (re-) generate the target foot file system.  This will not only
provide exact information about which versions of what have been used,
but you can also satisfy a number of other requirements you will most
probably have if you're targeting for a reproducable, professional
production process, like:

- making sure all the respective pristine source files / packages are
  available
- actually compiling everythinging in a controlled environment so you
  know you have all tools in place needed for such abuild
- generating a license manifest - for example, for the armv5te
  configuration of the ELDK v5.3, the build will include the follwing
  file:
  /opt/eldk/build/eldk-rel-v5.3-2012-12-12-c2836a8-armv5te/tmp/deploy/licenses/core-image-basic-generic-armv5te-20121212155956/license.manifest
  which looks like that:

  	PACKAGE NAME: acl
	PACKAGE VERSION: 2.2.51
	RECIPE NAME: acl
	LICENSE: GPLv2+

	PACKAGE NAME: at
	PACKAGE VERSION: 3.1.13
	RECIPE NAME: at
	LICENSE: GPLv2+

	PACKAGE NAME: attr
	PACKAGE VERSION: 2.4.46
	RECIPE NAME: attr
	LICENSE: GPLv2+

	PACKAGE NAME: base-files
	PACKAGE VERSION: 3.0.14
	RECIPE NAME: base-files
	LICENSE: GPLv2

	PACKAGE NAME: base-passwd
	PACKAGE VERSION: 3.5.26
	RECIPE NAME: base-passwd
	LICENSE: GPLv2+

	PACKAGE NAME: bash
	PACKAGE VERSION: 4.2
	RECIPE NAME: bash
	LICENSE: GPLv3+

	PACKAGE NAME: bc
	PACKAGE VERSION: 1.06
	RECIPE NAME: bc
	LICENSE: GPLv2+ LGPLv2.1
	...

  i. e. it contains exact information aboutpackage name, resipe name
  used to build it, software version and license used.

This is way more useful than a detached package list which will be out
of sync when you don't expect it.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A day without sunshine is like night.