Unfortunately no one can be told what fun_plug is - you have to see it for yourself.
You are not logged in.
puterboy wrote:
This standard approach would then more generally apply to all packages, not just the limited ones referenced in fun_plug and users would know that they only needed the run-time part if they wanted to just use the application but that they would need to also install the header file/lib part if they wanted to do their own compiling.
Does this make sense?
I know that some popular distributions do this, but I never understood why. It causes a lot of headaches, and often enough doesn't even save disk space.
Offline
puterboy wrote:
In a future release, one could take this idea a step further by converting fun_plug.tgz into a "super" tar file consisting of the following
fun_plug-base.tgz (consisting of all the partial package files)
less-418-3.tgz
rcorder-cvs-4.tgz
... and all the other complete packages that are included in the current fun_plug.tgz
It should become an installer, then. With nothing more than a telnet server, a curses-based menu, a downloader and the package installer.
Offline
fonz wrote:
puterboy wrote:
In a future release, one could take this idea a step further by converting fun_plug.tgz into a "super" tar file consisting of the following
fun_plug-base.tgz (consisting of all the partial package files)
less-418-3.tgz
rcorder-cvs-4.tgz
... and all the other complete packages that are included in the current fun_plug.tgzIt should become an installer, then. With nothing more than a telnet server, a curses-based menu, a downloader and the package installer.
That would be sweet of course but would require some significant work I imagine.
I was suggesting a near-term alternative that would probably take less time to implement than it is taking me to post this message
Offline
Just one practical question.
Are you likely to create something like a fun_plug-base.tgz package in the very near future or should I hack up my own for now using a bunch of diff's to figure out which are the files in fun_plug-base.tgz that don't belong to the other full packages?
I of course am not expecting you to do this but just wanted to know what your plans were before I started down a parallel (but less knowledgeable) path.
Thanks!
Offline
puterboy wrote:
Are you likely to create something like a fun_plug-base.tgz package in the very near future
http://www.inreto.de/dns323/fun-plug/0. … l#ffp-base
fun_plug.tgz is not updated, yet.
Offline
Thanks.
However, I noticed that the following links to busybox seem to be present in my (older) version of fun_plug.tgz but MISSING from the new ffp-base: (and as you can see, many of the missing busybox commands are pretty basic Linux functions)
./ffp/bin/addgroup
./ffp/bin/ar
./ffp/bin/cpio
./ffp/bin/delgroup
./ffp/bin/diff
./ffp/bin/dumpkmap
./ffp/bin/dumpleases
./ffp/bin/fdflush
./ffp/bin/fdformat
./ffp/bin/fetchmail
./ffp/bin/kbd_mode
./ffp/bin/loadfont
./ffp/bin/mt
./ffp/bin/patch
./ffp/bin/pscan
./ffp/bin/rpm
./ffp/bin/rpm2cpio
./ffp/bin/sendmail
./ffp/bin/setkeycodes
./ffp/bin/tcpsvd
./ffp/bin/tftp
./ffp/bin/tftpd
./ffp/bin/udpsvd
./ffp/sbin/brctl
./ffp/sbin/dhcprelay
./ffp/sbin/dnsd
./ffp/sbin/fbset
./ffp/sbin/httpd
./ffp/sbin/loadkmap
./ffp/sbin/makedevs
./ffp/sbin/udhcpd
It seems that the root of the problem is that all of these busybox applets have been dropped from busybox ver 1.12.1 vs. ver 1.11.1
Conversely, the following appear in ffp-base but not in my (perhaps older) version of fun_plug.tgz: (this is not necessarily a bad thing, I just wanted to make sure it was intentional)
./ffp/bin/run-parts
./ffp/lib/libthread_db-0.9.29.so
./ffp/lib/libthread_db.so
./ffp/lib/libthread_db.so.1
./ffp/sbin/rdev
Offline
Also just pointing out for interest that: less, passwd, , chpasswd
are now busybox functions vs. standalone functions. Not that this is bad or good - just pointing it out
Offline
The problem may be more with busybox 1.12 rather than with ffp-base since I now see that those links really get installed via install-busybox-links.sh.
But this brings up another question. If one updates the busybox program, how does funpkg know to remove the old busybox links and run the '.sh' script to install the new links?
Wouldn't it be better (and more consistent) just to include the links in the tar file (and in the package listing)?
Offline
Actually, it seems that the busybox files are duplicated in ffp-base.
Isn't this unnecessary since the purpose of ffp-base is to only include files that are not included in full packages?
Offline
Also, the file ./ffp/var/packages/ffp-base should probably include the following directories:
./ffp
./ffp/tmp
./ffp/var/packages
Also, the following man files don't seem to be listed in any of the /ffp/var/packages/<package> files:
./ffp/share/man/cat1
./ffp/share/man/cat1/less.1.bz2
./ffp/share/man/cat1/man.1.bz2
./ffp/share/man/cat1/rsync.1.bz2
./ffp/share/man/cat1/sntp.1.bz2
./ffp/share/man/cat8/useradd.8.bz2
./ffp/share/man/cat8/usermod.8.bz2
Offline
puterboy wrote:
The problem may be more with busybox 1.12 rather than with ffp-base since I now see that those links really get installed via install-busybox-links.sh.
But this brings up another question. If one updates the busybox program, how does funpkg know to remove the old busybox links and run the '.sh' script to install the new links?
Wouldn't it be better (and more consistent) just to include the links in the tar file (and in the package listing)?
Just to be clear, the problem is with busybox 1.12 and not just the missing links. These programs seem to be missing from busybox 1.12 itself (and creating the links alone doesn't help.)
When I reverted to busybox 1.11 (and re-installed the links) everything worked fine again.
(Note, I still think that for consistency the busybox package should include the links directly as part of the tar file to ensure that the pkg program both install and removes the links properly as busybox is installed/upgraded/removed)
[NOTE: sorry for the multiple posts but I have been posting sequentially as I have been figuring this all out -- hopefully, this will help you to create 100% clean packages ]
Offline
puterboy wrote:
Also, the file ./ffp/var/packages/ffp-base should probably include the following directories:
./ffp
./ffp/tmp
./ffp/var/packages
/ffp/tmp and /ffp/var/packages belong into the funpkg package. Including /ffp is not possible, since it must exist before the first package can be installed.
Also, the following man files don't seem to be listed in any of the /ffp/var/packages/<package> files:
./ffp/share/man/cat1
./ffp/share/man/cat1/less.1.bz2
./ffp/share/man/cat1/man.1.bz2
./ffp/share/man/cat1/rsync.1.bz2
./ffp/share/man/cat1/sntp.1.bz2
./ffp/share/man/cat8/useradd.8.bz2
./ffp/share/man/cat8/usermod.8.bz2
These are wrong and were fixed in the corresponding packages.
Offline
puterboy wrote:
Thanks.
However, I noticed that the following links to busybox seem to be present in my (older) version of fun_plug.tgz but MISSING from the new ffp-base: (and as you can see, many of the missing busybox commands are pretty basic Linux functions)
./ffp/bin/addgroup
...
It seems that the root of the problem is that all of these busybox applets have been dropped from busybox ver 1.12.1 vs. ver 1.11.1
Yes, I removed them (it's not an accident). Some of the programs are just useless on the DNS-323 (loadkmap, loadfont, etc). Full versions exists for others (ar, cpio, less, addgroup, delgroup, tftpd, httpd, udhcpd, dnsd, sendmail, patch, ...).
Conversely, the following appear in ffp-base but not in my (perhaps older) version of fun_plug.tgz: (this is not necessarily a bad thing, I just wanted to make sure it was intentional)
./ffp/bin/run-parts
./ffp/lib/libthread_db-0.9.29.so
./ffp/lib/libthread_db.so
./ffp/lib/libthread_db.so.1
./ffp/sbin/rdev
run-parts was removed from busybox (and rdev, too, I think). libthread is part of the uclibc package and needed for gdb.
Of course, I'm building ffp-base et all from the current versions of involved packages, so they might not match exactly the versions included in your fun_plug.tgz. If you don't want to clean up manually, your best option is probably to wait for an updated fun_plug.tgz - from then on, all files belong to packages, and obsolete files will be removed automatically.
Offline
puterboy wrote:
The problem may be more with busybox 1.12 rather than with ffp-base since I now see that those links really get installed via install-busybox-links.sh.
But this brings up another question. If one updates the busybox program, how does funpkg know to remove the old busybox links and run the '.sh' script to install the new links?
Wouldn't it be better (and more consistent) just to include the links in the tar file (and in the package listing)?
Yes, I want the busybox links in the busybox package, and I will add them as soon as I have split the coreutils part out of the busybox package. The links are not included at the moment, so you don't overwrite coreutils programs with busybox versions if you have coreutils installed.
Offline
fonz wrote:
puterboy wrote:
Thanks.
However, I noticed that the following links to busybox seem to be present in my (older) version of fun_plug.tgz but MISSING from the new ffp-base: (and as you can see, many of the missing busybox commands are pretty basic Linux functions)
./ffp/bin/addgroup
...
It seems that the root of the problem is that all of these busybox applets have been dropped from busybox ver 1.12.1 vs. ver 1.11.1Yes, I removed them (it's not an accident). Some of the programs are just useless on the DNS-323 (loadkmap, loadfont, etc). Full versions exists for others (ar, cpio, less, addgroup, delgroup, tftpd, httpd, udhcpd, dnsd, sendmail, patch, ...).
How did you decide which ones to drop and which ones not to?
Some of the dropped ones like 'diff' and 'patch' seem pretty basic to even a minimalist install. What do I need to do to include them back in?
Others like 'addgroup' and 'delgroup' are not critical since 'groupadd' and 'groupdel' exist but not sure what the logic was for dropping them.
Offline
puterboy wrote:
How did you decide which ones to drop and which ones not to?
Some of the dropped ones like 'diff' and 'patch' seem pretty basic to even a minimalist install. What do I need to do to include them back in?
Others like 'addgroup' and 'delgroup' are not critical since 'groupadd' and 'groupdel' exist but not sure what the logic was for dropping them.
For diff and patch, install the GNU versions (that are 'complete' and usable in all cases, while the busybox versions lack some options and are less trustworthy):
http://www.inreto.de/dns323/fun-plug/0. … #diffutils
http://www.inreto.de/dns323/fun-plug/0. … html#patch
addgroup and delgroup are just redundant. groupadd and groupdel are as easy to use. Having two programs providing almost the same function can be a source of confusion. There also have been problems with the busybox user/group management tools, which is why I've included the shadow package. busybox also lacks some important programs in this area (like usermod), so I'm removing all of busybox's user/group management functions.
PS: There are similar arguments for the other packages. dnsmasq provides DNS/TFTP functions, lighttpd is the HTTP server, etc. Often, the busybox functions are limited in certain ways, and often have bugs, because they get less testing.
Offline
Do you also plan to remove the duplication that all the busybox files are also in ffp_base? (since that would then be the only example of a full package being also included in ffp_base)
Offline
puterboy wrote:
Do you also plan to remove the duplication that all the busybox files are also in ffp_base? (since that would then be the only example of a full package being also included in ffp_base)
Yes. The only remaining problem with busybox now is that it contains still a lot of duplicates from the coreutils package. The plan is to create two versions of busybox: a complete one with lots of busybox tools (suiteable for small ffp installations), and a smaller one with all duplicates removed. When that's done, I remove busybox and the links from ffp-base. The links will then be part of the busybox packages.
Offline
Fonz - thanks for all the help and responsiveness to my suggestions.
I now have my system all set up clean and pretty minimalist which makes me
I think the only minor remaining nits are the following:
1. The duplication of busybox within ffp_base even though it is available as a separate standalone package (and it sounds like you have a plan to fix this)
2. The fact that creating the busybox links requires running install-busybox-links.sh which requires running a separate shell script and which also means that the links are not updated or removed properly when the busybox package is upgraded or removed. (and again it sounds like you have a plan to address this)
Offline
puterboy wrote:
1. The duplication of busybox within ffp_base even though it is available as a separate standalone package (and it sounds like you have a plan to fix this)
2. The fact that creating the busybox links requires running install-busybox-links.sh which requires running a separate shell script and which also means that the links are not updated or removed properly when the busybox package is upgraded or removed. (and again it sounds like you have a plan to address this)
Yes, I intend to fix all this. The number of packages in ffp has grown much faster than the 'supporting infrastructure'. It takes some time to settle (this is why it's still 'beta').
Offline