* added some TODOs

git-svn-id: https://svn.pengutronix.de/svn/ptxdist/trunks/ptxdist-trunk@7093 33e552b5-05e3-0310-8538-816dae2090ed

1 files changed, 118 insertions, 1 deletions

diff --git a/TODO b/TODO
index afe4ca2a1..5cb015e8e 100644
--- a/TODO
+++ b/TODO
@@ -212,6 +212,123 @@ TODO for 0.10.x
     best with host visualisation
 
 [.] jbe: more help texts
+[ ] bbu: audit *.in and *.make files, broken install definitions everywhere [tm]
+	 (mostly c&p errors, probably)
+	 
+[ ] bbu: reimplement cuckoo-test for ptxdist 0.10 series
+	 - files w/ wrong build-arch
+	 - missing libs
+	 - statistics
+	 - stripped / non stripped files
+	 
+[ ] bbu: reimplement generic pre- and post-flight checks for 0.10.x
+	 - dependency checks
+	 - cuckoo-test
+	 - user defined checks
+	 - package tests
+	 - in-system test -> ltp
+
+[ ] bbu: generic logging aproach w/ single and combined logs
+	 - combined log for normal use
+	 - build-logs per package, test-suite, etc would
+	   support features like 
+	   	- "quiet build", while still providing the full error 
+		   output of the failing target
+		- helpdesk notification fetaures
+	 	- build statistics
+	 	- better support for GUI driven builds
+
+[ ] bbu,rsc,mkl: brain storming session
+
+	Discussion about the whole PTXdist build-,
+	deployment- and testing-mechanics:
+ 	
+	- Support different target package formats
+	  Rationale: - Some standardization aproaches like carrier grade linux
+		       or the linux standard base make rpm or dpk packages 
+		       mandatory.
+		     - Users asked for it
+	  Which package formats would be useful ?
+	  		- ipkg
+			- deb
+			- rpm
+			- openpkg
+			- plain directory tree / tar[.gz]
+	  ! Depends: Check rpm and deb database footprint
+	  ! Depends: Discussion about the current installation scheme
+
+	- Support binary package distribution
+	  Rationale: Most Customers donīt want to build the 
+	  	     base System on their own. They want a
+		     well defined base system and then apply
+		     some changes, add files (probably on the fly)
+		     by installing binary packages.
+	  ! Problem: This might break the current PTXdist philosophy
+	  	     (executeable documentation)
+	  ! Depends: We would need some kind of install-filter or exclude-list
+	
+	- Deployment / Testing Frontend (maybe GUI driven)
+	  Rationale: needed in a binary package distribution scenario
+	  	     to customize the installation from a generic 
+		     binary package.
+	
+	- Support precompiled customer environment
+	  Rationale: This would reduce compile times for 
+	  	     the customer, since he would start 
+		     directly w/ his own application
+		     w/o the need for a full ptxdist run.
+	  ! Problem: Build Hierarchy is not relocateable
+	  	     -> libtool problems
+	  ! Problem: Make depends on timestamps
+	  Possible solutions:
+	  	     - create intermediate build labels / paths
+		     - tweak things during installation 
+		       (dirty, dirty ... how do we handle updates?)
+		     - Provide a "full blown" toolchain with all
+		       host-tools and chroot into it
+		       (dirty, dirty ... needs root privileges)
+		     - Provide a "full blown" toolchain with all
+		       host-tools inside a virtual machine, 
+		       vmware image or CoLinux
+		       (dirty, slow, but runs even with Windows)
+		       (nasty, since it would be some kind of closed box solution)
+		       (problem: how do we handle alternative toolchains in this case?)
+
+	- Support Partitioned Images
+	  ! Problem: We donīt want to use root privileges
+	  ! Problem: Generate valid Partition Tables
+	  ! Problem: ipkg list has to work inside the
+		     target system, so we would need 
+		     two or more diffenrent installation "views":
+		     - The partition image generation view,
+		       which 
+		       a) respects partition boundaries
+		       b) rewrites the resulting installation
+		          paths respectively.
+		     - The binary target package view (i.e. ipkg)
+		       which 
+		       a) generates apropriate pre- and post-
+		          installation scripts to i.e. remount
+			  the partitions read/write
+		       b) creates binary packages, rooted in 
+		          "/" on the target.
+		     - An optional "user-view", where something 
+		       else can happen, i.e. transfering stuff
+		       to an ftp server or mounting an image 
+		       with root privileges or as user via fuse.
+		       
+	- TODO: 
+		- Create Use Cases:
+			- What is covered by the current design
+			- What would be nice, well designed and sane
+			- What does $JON_DOE_HACKER  want
+			- What does $JON_DOE_HACKER _need_
+			- What does $CUSTOMER  want
+			- What does $CUSTOMER _need_
+		- Draw the big picture :-)
+		- Create Roadmap
+
+
 
 -------------------------------
 target: host-ipkg-utils.install
@@ -267,7 +384,7 @@ make: ***
     the "current" command; some continue parsing and some exit.
 
 [ ] mol: add possibility to 'ptxdist print' more than one variable in
-    one make call
+    one make call  bbu: maybe some kind of "ptxdist env" as in env(1) ?
 
 [ ] check if ${PTXCONF_PREFIX} can be written to and barf if not