Rod Whitby <rod@...> writes:
> I usually put /opt/bin and /opt/sbin at the end of the path, the rationale
> being the optware packages
> usually point to things directly instead of relying on the path. So
> ipkg-opt does optware installation
> and just ipkg does openwrt installation.
I'd rather use coreutils than busybox for lots of "normal" activities so
find it easier to have /opt/bin at the start of the path, I can see why
others may feel differently. I'll just update the wiki to explain both
options and their relative merits.
> Recent Kamikaze has /etc/config/fstab where you can automatically mount
> /opt and swap (I added this
> specifically to support Optware, but it's a great general purpose facility).
In that case I'll stick with editing /etc/init.d/custom-user-startup until
/etc/config/fstab make it into a release.
> An /etc/init.d/optware script is definitely needed - see the
> source directory for other bootstrap
> packages for a good one to use (e.g. optware/sources/fsg3v4-bootstrap).
OK, will do.
> Any optware packages that assume that libpthreads, libssp and libstdc++
> are available should list them in
> the dependencies so that they will be automatically installed - please
> update any packages that don't do this.
Unfortunately I don't think that will work because the libraries are
openwrt packages and the applications are optware packages so with the
recommended setup of separate versions of ipkg one ipkg can't see what
packages the other has installed. I guess it would be possible to create
the library packages as optware packages but that is a bit wasteful,
especially for users using flash drives for /opt. Another option would be
to recommend installing those libraries as part of the bootstrap process. I
suppose another option would be to create optware packages that just
contained a postinstall script that did /usr/bin/ipkg install on the
> Dunno what to do about /etc/services ...
If I'm going to create an openwrt-bootstrap package I could put /etc/services
in there, a bootstrap package can't be expected to obey the normal rule about
not writing outside /opt.
Further thoughts (possibly heading towards stuff that should be on the devel
/etc/passwd is a bit bare, should the bootstrap package append entries for lp,
ftp and mail that are in unslung and probably others by default or should any
package that requires those by updated to depend on and use adduser?
When connecting a printer, hotplug2 creates /dev/lp0 owned and only writable
by root, cups expects it to be writable by a non root user (at the moment it
wants nobody but I haven't yet traced if that is because lp doesn't exist).
The only sensible way to fix this appears to be a change to
etc/hotplug2-init.rules as a change elsewhere won't persist through a
printer unplug / replug sequence.
There isn't a native toolchain for uclibc targets, presumably because the
version of crosstool you use doesn't support canadian cross builds for uclibc.
I could package up system headers and static libraries from the toolchain
easily enough as uclibc-dev but I'd need someone using the other uclibc
targets to make it work on those too. binutils seems to package up fairly
easily. gcc looks like it should be doable with a bit more work, I got a
version built that would compile hello world but I had to hand edit the
link command before it would link. When I found the patch for that I
applied some other recommended patches and haven't yet fixed the problems
that introduced. So a native toolchain looks to be within reach but my
decision to use the same version and patches as used in the openwrt
toolchain for gcc may well mean it requires effort to port to