An 'early' morning thought about the future of PWL

[Ralph Stickley]

Hey, 
Sounds like your on to something here...except for building the pwlconfig
packages (either tar or RPMs) I think most of this is done with pwlconfig
now...maybe I missed something...

--- Adi Linden <adi@adis.on.ca> wrote:
> I thought about ways to automate the sources for PeeWeeLinux. Here's an
> idea I had while showering this morning. Right up front, to implement it
> it would require sophisticated knowledge of rpm. Something I don't have
> but nonetheless its an idea I'd like to share...
> 
> First PeeWeeLinux would have to build from RedHat source rpms. Packages
> that do not exist as source rpm would have to be created specifically for
> PeeWeeLinux or for Redhat Linux in gerneral.
> 
> First take the original source rpm and manually edit the spec file to
> build a rpm suitable for PWL. Also, edit the sources to compile as
> required for PWL. I.e. the libs to use, which files to install, etc. 
> Create a patch file to patch the necessary changes into the source rpm
> files.
> 
> Build a PWL specific rpm from the patches source rpm.
> 
Ok, let me see if I can figure this out...

RH RPM 6.x--> manual process --> PWL-RPM.patch file --> PWL-RPM

then

RH RPM 6.x --> RPM process with PWL-RPM.patch file -> PWL-RPM

the "PWL-RPM.patch_file" plus the RH source disk is all you need...
sounds good.

> Use a defined mount point for the PeeWeeLinux filesystem being build
> independed of where PeeWeeLinux has been extracted to. I.e. /mnt/PWL.
> 
Hmmm...shouldn't keep this within the development environment ??
...maybe Embedded-Build/projects/xxx/mnt...why would you use the same
mount point for a project specific filesystem  ??

Ohhh...wait...you want to basically extract all the tar files we have now
into one pwl file system, then let the user pick from this file system???
Seems like an added step, not sure of any advantages...
Ok, I'm confussed...


> Use rpm in a similar mode as the RedHat install disks do. That is install
> the PWL specific rpms in /mnt/PWL rather than the current file system.
> 

Ok, not sure what RH does with the RPMS..I thought they just got extracted
into the /usr/src/linux/ directory structure..again, I think I'd prefer to keep
everything within the "Embedded-Build" structure, however, any good reason
not to would sway me :-)

> This would eliminate the use of tar to manage files. The pwlconfig script
> would have to do the following steps to build a project:
> 
> 1. Menu to select which packages to build and install
> 2. Submenu to select which files to install from the packages
> 3. Configure the location of RH source rpms and source rpm that do not
> come with RH
> 4. Patch the RH source rpms to turn them into PWL source rpms
> 5. Build the PWL specific rpms from source rpms

...this creates the PWL-RPM.patch files for each rpm..ok..I envision these
fitting into the project as follows:

Embedded-Build/source/patches

Scripts or patches or whatever, that are used to turn a lowly RH RPM into
a PWL-RPM file

Embedded-Build/packages
Embedded-Build/packages/package A
Embedded-Build/packages/package B     

These are the "global" optimized binaries used for every
project...these can be tar or RPM files, shouldn't be hard to switch...

This is where the RPM files reside after being "processed" by the PWL-RPM.patch
files. The pwlconfig menu item (yet to be added :-) "Build PWL-RPM" would
let you pick a patch file and generate the PWL-RPM file.  This would
be inserted into the packages directory.


> 6. Condition the /mnt/PWL filesystem for the new system

not sure what this is..

> 7. Install the selected files from PWL rpms in /mnt/PWL
> 8. Install any custom config files into /mnt/PWL, overwriting any existing
> configuration

I think these should be project specific...I could be building a router and
a print server and a thin client..these are all in seperate directories.

I think this is the process I'm doing now with the tar files, only each project

keeps their file system seperate within the project directory:

Embedded-Build/projects/router_486/mnt                    
Embedded-Build/projects/thin_client/mnt                    

This is a "mount point" where the project (ie. "router_486") gets built from
the project specific configuration files. All files are extracted and allows
the user to tweak the project before it is loaded on to some device. at this
point, we are device independent.

Embedded-Build/mnt

When you load a device, it gets mounted in the "Embedded-Build/mnt" directory
until you unmount it and go to another project.  This mount directory is
bascially a temporary mount point used for every project, but can be used
to mount any device.

> 8. Offer choice of what to do with the newly created system, i.e. build a
> ramdisk, load a DOC, make a bootable CD...
> 
Almost got this working...I have a new script that does DOC and flash disk...
Adding the ramdisk and bootable CD should be easy, once I know what needs
to be done.

> The advantages I can see:
> - The PWL distribution would no longer require any sources but only patch
> files containing package description, help information (things that could
> be displayed by pwlconfig) and the actual patch to the RH source rpm.

Yes...I have the source, I shouldn't have to download it again...

> - Perhaps eases the migration to newer RH versions as they are released.
> 
> The disadvantages:
> - Building an initial PWL development environment could be 'very' time
> consuming and diskspace consuming since everything has to be compiled
> first.
> - Defenitely RH specific!
> 

Only RH specific where the patches to the RPMS are concerned. After we
have built our RPMS (or tar files), the configuration tool does not care 
what order the files are in or what the directory structure is....

> I guess an option would be to have a package of pre-compiled PWL rpms
> available. That would make PWL a 'real' full-fledged distro for embedded
> stuff :)
> 
> Perhaps I should get and dig into 'Maxximum RPM' sometime. Maybe that
> would be a ToDo wishlist item for the next RedHat release, when a few
> package for PWL will have to be re-done...
> 
> TTYL,
> Adi (dreaming... :)
> 
> 

I'm not sure how this differs from what you have done to build the
existing tar files.  Now, (or planned real soon now) we do the RPM extract to
our "Embedded-Build/source" file system, then apply the patches and build tar
files ...But instead of building tar files, create new RPM files...

Is there an advantage to building the RPM as opposed to the tar files? maybe
processing them might be easier...

Shouldn't matter if these are RPMs or TARS, but processing them into specific
projects should be able to use the same pwlconfig as now, just change from
tar file processing to RPM file processing ???
Either way, each project is unique, and built from some "pwl" source
repository,I guess I need to get up to speed on the RPM stuff too.

---------------
On a seperate note, I noticed that Transmetta is desiging their Linux to
work for "Mobile" applications.  OK, that to me means embedded (what else is
low power for :-)

Anyhow, while they haven't released anything yet, they have "hinted" that
they have spent time doing special programs like "touch screen keyboard"
and "handwritting recognition" (ie.palm pilot work alike programs).

Also, these are supposedly built from the Debian distribution.

Soooooo....Assuming that Transmetta has not built any sort of development 
environment (which true UNIX people *NEVER* do), I think it would be nice
to be able to get these programs and add them to our embedded RH environment.

Thus, get their RPM (or whatever Debian uses) and process them into 
our tar (or RPM) format.  Now you can add these to your project and they
should just work....

pwlconfig should allow you to work with applications from any distribution.
There is nothing specific in "pwlconfig" that would prevent this from 
working.

The PeeWee Distribution is useable when we can :

1. Create several default projects 
   (ie. Embedded-Build/projects/[router|thinclient|server|print server|...])

2. Create project configurations for each of these projects 
   (ie. use pwlconfig V1.0 for each of the default projects listed above)

3. Process "source files" into optimized binaries 
   (ie.fill up the Embedded-Build/patches with the PWL-patches_for_RPM_x)

On going work is to:

A. refine pwlconfig for more devices and features
B. keep building patch files for each new version of RH
C. build patch files for special applications

If we can do this, it will be a very usable (and unique) environment for
embedded Linux development ( and World Domination will be at hand :-)) !!!

Hmmm...Let me know if we're on the same page here...I could be missing
something

Later,
Ralph





__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com