[oe-commits] org.oe.packaged-staging docs/packaged-staging.xml: be more verbose and talk about chroot a bit

[koen commit]

docs/packaged-staging.xml: be more verbose and talk about chroot a bit

Author: koen at openembedded.org
Branch: org.openembedded.packaged-staging
Revision: f1b6b0ac95d6e1640ed0b572df5804fe87003df3
ViewMTN: http://monotone.openembedded.org/revision.psp?id=f1b6b0ac95d6e1640ed0b572df5804fe87003df3
Files:
1
docs/packaged-staging.xml
Diffs:

#
# mt diff -rafae21a186c208ae595815b70ea02bde36c233ab -rf1b6b0ac95d6e1640ed0b572df5804fe87003df3
#
# 
# 
# patch "docs/packaged-staging.xml"
#  from [2a386bd706b6460a98a02c7ee107969581036012]
#    to [a769dff9ee283d18b0eb24bddd09f8d415c184f9]
# 
============================================================
--- docs/packaged-staging.xml	2a386bd706b6460a98a02c7ee107969581036012
+++ docs/packaged-staging.xml	a769dff9ee283d18b0eb24bddd09f8d415c184f9
@@ -26,9 +26,9 @@
 
 <para>First we need to identify three classes of packages:
 <itemizedlist>
-	<listitem><para>'native'  - These packages run on the buildsystem (e.g. quilt-native)</para></listitem>
-	<listitem><para>'cross'   - These packages run on the buildsystem, but creates things for the target system (e.g gcc-cross)</para></listitem>
-	<listitem><para>'regular' - These packages run on the targetsystem (e.g. glibc)</para></listitem>
+	<listitem><para>'native'  - These packages run on the buildsystem (e.g. quilt-native), OE doesn't package these</para></listitem>
+	<listitem><para>'cross'   - These packages run on the buildsystem, but creates things for the target system (e.g gcc-cross), OE doesn't packages these completely. It will e.g. create a libgcc1 packages, but not a gcc-cross package</para></listitem>
+	<listitem><para>'regular' - These packages run on the targetsystem (e.g. glibc), OE does packages these</para></listitem>
 </itemizedlist>
 </para>
 <para>
@@ -53,13 +53,13 @@ If we have packages that can be installe
 <section>
 	<title>Start over from scratch</title>
 <para>
-For each to be built package we will repopulate the staging directory from scratch. The benefits are a clean environment and avoids packages picking stuff up at random. Conflicts when installing packages can only happen when two different providers are trying to install the same file. This can only be a bug of the OpenEmbedded meta data. This approach will not require any conflict handling or resolution
+For each to be built package we will repopulate the staging directory from scratch. The benefits are a clean environment and avoids packages picking stuff up at random. Conflicts when installing packages can only happen when two different providers are trying to install the same file. This can only be a bug of the OpenEmbedded meta data. This approach will not require any conflict handling or resolution. This will break a multithreaded bitbake, since only one tasks can access staging reliably.
 </para>
 </section>
 
 <section>
 	<title>Incrementally installing packages</title>
-<para>In contrast to repopluating the staging area from scratch we install additional dependencies and remove conflicting packages. The installing and removing of packages is assumed to be faster than repopulating from scratch. Once a package completed we could consider removing the non-native depends to avoid a growing staging directory. One issue is with the clean task. We could assume that cleaning a package will remove it from the staging area as well. There is one possible problem with it. Let us assume we want to clean quilt-native, virtually every package DEPENDS on it, we would have to clean the staging area completely. If this is the wished behaviour needs to be discussed. 
+<para>In contrast to repopluating the staging area from scratch we install additional dependencies and remove conflicting packages. The installing and removing of packages is assumed to be faster than repopulating from scratch. Once a package completed we could consider removing the non-native depends to avoid a growing staging directory. One issue is with the clean task. We could assume that cleaning a package will remove it from the staging area as well. There is one possible problem with it. Let us assume we want to clean quilt-native, virtually every package DEPENDS on it, we would have to clean the staging area completely. If this is the wished behaviour needs to be discussed. This should be safe for a multithreaded bitbake, given that no two do_stages access staging at the same time.
 </para>
 </section>
 </chapter>
@@ -135,7 +135,7 @@ python do_write_ipk_list () {
 }
 </screen>
 
-So now OE will spit out a spawnfile for each revision of a recipe, instead of one per recipe as the pkgmap code does.
+So now OE will spit out a spawnfile for each revision of a recipe, instead of one per recipe as the pkgmap code does. This is needed to get versioned dependencies to work in the future.
 </para>
 </section>
 
@@ -170,6 +170,8 @@ STAGING_BASEDIR         = "${STAGING_LIB
          oenote "Spawn file not found!"
  fi
 </screen>
+
+The sed is needed to fix the .la files to avoid linking problems. Using a chroot for building would avoid this problem. I've not encountered troubles with pkgconfig files  yet, so those remain untouched.
 </para>
 </section>
 
@@ -238,7 +240,8 @@ fi #if !glibc intermediate
 }
 </screen>
 
-The above gets prepended to the do_stage() method specified in the recipe. I works by rotating away the staging dir so the next step can easily find the added files:
+The above gets prepended to the do_stage() method specified in the recipe. A 'shared' ipkg.conf is used to make tracking of packages easier, but could result in target binaries ending up in staging.
+It works by rotating away the staging dir so the next step can easily find the added files:
 
 <screen>
 do_stage_append() {
@@ -282,6 +285,8 @@ ipkg install newly-packaged-stuff
 ipkg install newly-packaged-stuff
 </screen>
 
+This will avoid a lot of troubles and isn't hard to implement and would be a nice task for someone planning to work on this.
+
 </para>
 </section>
  
@@ -295,6 +300,14 @@ The metadata in the packaged-staging bra
 <para>
 The metadata in the packaged-staging branch well, once it's done building the toolchains. The infamous 'bitbake nano' testcase works as well as other packages present in the packaged-staging branch.
 </para>
+<para>
+The whole concept of ad-hoc creating seperate packages for native and cross packages is flawed, however. The correct solution would involve building the needed native stuff with MACHINE=native and ASSUME_PROVIDED_native = "bunch of stuff".
+Stuffing all archs in the ipkg.conf is wrong as well, since it could allow installing of x86 stuff in an ARM based staging. I have no real solution for that yet.
+</para>
+<para>
+The hardcoded use of ipkg sucks, but it's the only package format OE can generate reliably. Using checkinstall would solve that, but that would introduce even more bootstrap and self-hosting problems.
+</para>
+
 </section>
 
 <section>
@@ -320,8 +333,14 @@ The code for both items is in packaged-s
 </screen>
 
 The code for both items is in packaged-staging.bbclass already, but in different methods. Estimated time: 30 minutes.
-
 </para>
+<para>
+To completely solve chicken and egg problems OE should have -bootstrap packages that contains functional replacements, or require on things from RequiredSoftware to build. We should consider using the shell version of ipkg to install packages into staging/cross/work. 
+</para>
+<para>
+A good follow-up for this SoC would be to investigate using chroot for compiling combined with something like mount --bind/unionfs/checkinstall to get rid of most relocation issues. Using a chroot would also be safe for a multithreaded bitbake, since each build can have its own sandbox.
+</para>
+
 </section>