PeeWeeLinux Ideas

[Adi Linden]

Hi Ralph,

Just making notes of some random PeeWeeLinux ideas. Thought I'd email them
to you to see what you think...

I cc'd this to the PeeWeeLinux lists. Perhaps someone else using PWL has
ideas or suggestions, too?

Package Names
-------------

Currently packages are named like thttpd-1.2.3.tar indicating the name and
version of the software. This naming applies to all packages build from
original sources regardless of whether they came from the original author
or were taken from a SRPM.

Currently packages build from precompiled binaries (RedHat rpm or running
system) are named thttpd-1.2.3-rh.tar to indicate the fact they were not
compiled and taken from the system. Perhaps still stripped and dependency
checked and associated scripts changed, but no other changes.

Would it make sense to start adding a version numer similar to what RedHat
does? Like creating thttpd-1.2.3-1.tar for the initial release. When a
package is changed due to bugfixes, etc, the version number of the package
could be incremented like thttpd-1.2.3-2.tar. Obviously this wouldn't
happen with every PeeWeeLinux release but as bugs are reported and fixed
or as other features are added.

File List
---------

If you look at the Embedded_Build directory, there is a file called
Filelist (I think) which contains the package names and files associated
with it. Would it make sense to keep a file like it, indicating the
included package name and the related files?

As one of the todo tasks I want to eliminate duplicate files in packages.
Since networking is an obvious feature of Linux I will change the
arrangements of packages in a way that it assumed that networking is going
to be installed. I want to remove all the configuration files from the
base_filesystem and base_libs packages and create a base_script or
base_configuration package that contains all those. Things to include
there would be:

/etc/services
/etc/protocols
/etc/nsswitch

Subsequently I am removing those files from their duplicate places...

Should the Filelist file include the descriptions entered in the
package.README files? I tend to not to include them to not clutter up the
filelist file.

Maintaining the filelist file would make it easy to chack for duplicate
files within the PWL distribution and to enable on to quickly find a
particular binary, i.e. which package includes 'su'?

Distributing PWL
----------------

I am thinking about creating a PWL packages directory on the server in
which to keep all the packages for individual download. Perhaps gzip the
packages, though. This would allow for individual packages to be
downloaded rather than the complete archive if some packages are added.
Also, it would allow for newly build packages to be made available
immediately without having to wait for a new release.

I am a bit torn between the idea of creating a new release too often or
not often enough. Just adding a couple of packes doesn't necessarily
justify creating a new release, especially if some known bugs haven't been
addressed. On the other hand I don't want to not release new features and
additions because I won't have time to address some issues immediately. I
need some guidance here.

Closing
-------

This all comes to mind because I will have a crude X package compiled from
sources soon. This will add some 40MB to the source distribution. I think
it's a bit of a waste to have to download a 50MB file for some minor
changes... I guess there's always the binary distribution.

TTYL,
Adi

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