PeeWee todo...was lilo failed

[Adi Linden]

Hi Ralph,

> Looks like a good list...just keeps going and going and ...

Hehehehe... :)

> How about:
>    - manual/scripts for building your own packages
>      (we need to constantly upgrade our files - you
>      shouldn't be the only one having fun making packages!:)

Actually, making packages is easy if you get into using rpm. That's really
all ther is to it. I don't think there's much that could be done with
pwlconfig.

> rd.log - I'll take a look at this, I think I can popup a window 
> that displays the log file...didn't notice that you 
> had already created a log file, cool...

There is nothing send to /dev/null in the pwl_target* scripts. Whatever
isn't send to the success/unsuccess screen is captured by rd.log.

> To do the dual boot, I think you can globally replace the
> hardcoded partition number grep "}1" in pwl_target*
> with a variable rd_part or whatever (just add one for the
> multi-partition stuff ?) 
> 
> Now add another default variable for the base partition 
> number (default to 1 and you will have the same code
> you have now)...change to 6 and you can load/mount to /dev/xxx6.

It's not that easy because the pwl_target_load functions include embedded
commands to fdisk your device. You don't want that on a dualboot :-O

So it'll be another target option with some specific parameters (Target
Partition) and it's own pwl_target_load function.

> Now, you have to build the lilo thing for dual boot. Is there
> any way you can seperate lilo into seperate functions ? (I still
> like the menu option to lilo, but that may just be me:)

Lilo menu? 

> I never got back to the kernel thing (our priorities shift with
> the weather :-o)...glad to hear it worked  for you, maybe I'll 
> try that with the next release.

I am pretty busy building the network. Lots happening all at once so there
isn't much time left doing PeeWeeLinux development. It's also accounting
time :-O  I am caught up with most, though.

One thing the kernel build still needs is a means to integrate a build
kernel into a project. Perhaps buy creating a custom package or a package
that gets added to the Embedded_Build/package/Custom_Kernel (new)
directory???

If the build kernel is added to the custom files structure it might mean
plenty of manual labour to remove files if a new kernel is compiled.
Creating a kernel tar file to be placed into the packages structure might
be the answer.

Another thought that came up was the ability to move all the build
directories outside of the Embedded_Build directory. So one can update to
a new PeeWeeLinux release without loosing all the pre-existing content. It
would also allow for PeeWeeLinux to run from CD without copying the whole
structure to HD. This means changing most or all paths in pwl_functions to
absolute paths... 

TTYL,
Adi

---------------------------------------------------
See the list archives at http://adis.on.ca/archives/
See the PWL homepage at  http://peeweelinux.com
---------------------------------------------------