July 21, 201015 yr Author I think we are overthinking it. Plain old Slackware packages work... and work very well. Even if we never had anything else, that would carry a lot of water in terms of enhancing a lot of unRAID installations. If you have something complex, then deal with that complexity in the doinst.sh script. If you have a standard Slackware package that needs to be altered to work properly on unraid, just untar it, alter it, and tar it back up.... don't jump through hoops with a bunch of chewing gum and bailing twine to make it more difficult than that. Indeed, a plugin for the new web GUI only needs to be 2 files to be untarred into /usr/local/wegGui.... that can be a super simple .tgz file. No install script needed at all. I don't see that scaring off any novice developer. I had a comp sci proff once give us an assignment to write a blackjack program, but part of the spec, was he defined which integer values would represent each card. It took a great deal of work, and some creative function calls, but I wrote a complex function to make the conversion, and was quite proud of myself. I got points taken off, because I couldn't see the forest for the trees -- a simple, 52 lines of array assignments would have been much simpler, and taken less time to write.... and that was the precise lesson of the assignment. Rather than hold back till everything was done, Tom released a very early beta, so we can use, experiment, and give feedback. We can always add to the package management "intelligence" later.... starting with a basic of standard Slackware packages for now does nothing to limit enhancements later, but does, I think, provide a great deal of opportunity to experiment and try stuff.
July 21, 201015 yr How would you define multiple executable lines in the .ini file? and at what point is it appropriate to move those multiple executable lines to another shell. Questions like that are exactly why we are hashing all this out... (hopefully without egos getting in the way.) I'm not an experienced "php" coder, and I've not looked at the "ini" classes Tom used as of yet. I'm not focusing on how we will be doing something, but more of what we need to consider. My experience in package management has evolved as unMENU's package manager did. FWIW, The use of gawk for unmenu and the .conf definitions is awesome, had it been in perl or miniperl I would have joined the fray. Did I ever mention I once was in e-mail contact with Larry Wall. (Waaaaaayyyy back in the early days of USENET, when he first wrote PERL) Unfortunately, it was not part of the UNIX systems I was on, and never got to learn much of it over the years, my shell and awk were too strong. regardless, unRAID did not have perl, otherwise I might have used it. On the other hand, there is a unMENU .conf file for it. It has 5 installation lines and also installs "make" (which perl uses for CPAN): PACKAGE_INSTALLATION which make >/dev/null 2>&1 || installpkg make-3.81-i486-1.tgz PACKAGE_INSTALLATION [ ! -f /usr/bin/make ] && echo "'make' not installed. perl installation aborted." PACKAGE_INSTALLATION [ ! -f /usr/bin/make ] && exit PACKAGE_INSTALLATION installpkg perl-5.10.0-i486-1.tgz PACKAGE_INSTALLATION PERL_MM_USE_DEFAULT=1 perl -MCPAN -e 'install MP3::Tag'
July 21, 201015 yr I think we are overthinking it. Plain old Slackware packages work... and work very well. Even if we never had anything else, that would carry a lot of water in terms of enhancing a lot of unRAID installations. If you have something complex, then deal with that complexity in the doinst.sh script. If you have a standard Slackware package that needs to be altered to work properly on unraid, just untar it, alter it, and tar it back up.... don't jump through hoops with a bunch of chewing gum and bailing twine to make it more difficult than that. I don't doubt it. For the most part, installpkg has worked for me. I have had the need to do a preinstall preparation and a post install preparation. So I actually do see this occurring in the more complex setups. I've never modified the doinst script unless I am the package maintainer. I usually prefer to get the package source build it and "add" my scripts to it. Leaving the virgin source alone. My NFS post install script was a good example. When I was testing exim, I had to move some directories around and mount a tmpfs on /var/spool in order to get it to work. Something I just preferred to work on externally and directly. There are some packages or plugins that will require multiple operations post installation. I'm just thinking that one day these "hooks" will be needed. After seeing the .conf file I see the need for them. There's a reason the thecus had them. I only present this for example. root@atlas /tmp #gunzip powerdown-1.02-noarch-unRAID.tgz root@atlas /tmp #tar -tvf powerdown-1.02-noarch-unRAID.tar drwxr-xr-x root/root 0 2008-10-04 15:00 ./ drwxr-xr-x root/root 0 2008-10-04 15:00 etc/ drwxr-xr-x root/root 0 2008-10-04 15:00 etc/rc.d/ -r-xr-x--- root/root 9128 2008-10-04 15:00 etc/rc.d/rc.unRAID drwxr-xr-x root/root 0 2008-10-04 15:00 usr/ drwxr-xr-x root/root 0 2008-10-04 15:00 usr/doc/ drwxr-xr-x root/root 0 2008-10-04 15:00 usr/doc/powerdown-1.02/ -rw-r--r-- root/root 1902 2008-10-04 15:00 usr/doc/powerdown-1.02/powerdown.SlackBuild -rw-r--r-- root/root 1052 2008-10-04 15:00 usr/doc/powerdown-1.02/slack-desc drwxr-xr-x root/root 0 2008-10-04 15:00 sbin/ -r-xr-x--- root/root 524 2008-09-03 17:32 sbin/powerdown drwxr-xr-x root/root 0 2008-10-04 15:00 install/ -rw-r--r-- root/root 2647 2008-10-04 15:00 install/doinst.sh -rw-r--r-- root/root 1052 2008-10-04 15:00 install/slack-desc root@atlas /tmp #mkdir install root@atlas /tmp #mv postinstall.sh install root@atlas /tmp #tar -rvf powerdown-1.02-noarch-unRAID.tar install/postinstall.sh install/postinstall.sh root@atlas /tmp #gzip -9v powerdown-1.02-noarch-unRAID.tar powerdown-1.02-noarch-unRAID.tar: 81.5% -- replaced with powerdown-1.02-noarch-unRAID.tar.gz root@atlas /tmp #tar -tvzf powerdown-1.02-noarch-unRAID.tar.gz drwxr-xr-x root/root 0 2008-10-04 15:00 ./ drwxr-xr-x root/root 0 2008-10-04 15:00 etc/ drwxr-xr-x root/root 0 2008-10-04 15:00 etc/rc.d/ -r-xr-x--- root/root 9128 2008-10-04 15:00 etc/rc.d/rc.unRAID drwxr-xr-x root/root 0 2008-10-04 15:00 usr/ drwxr-xr-x root/root 0 2008-10-04 15:00 usr/doc/ drwxr-xr-x root/root 0 2008-10-04 15:00 usr/doc/powerdown-1.02/ -rw-r--r-- root/root 1902 2008-10-04 15:00 usr/doc/powerdown-1.02/powerdown.SlackBuild -rw-r--r-- root/root 1052 2008-10-04 15:00 usr/doc/powerdown-1.02/slack-desc drwxr-xr-x root/root 0 2008-10-04 15:00 sbin/ -r-xr-x--- root/root 524 2008-09-03 17:32 sbin/powerdown drwxr-xr-x root/root 0 2008-10-04 15:00 install/ -rw-r--r-- root/root 2647 2008-10-04 15:00 install/doinst.sh -rw-r--r-- root/root 1052 2008-10-04 15:00 install/slack-desc -rw-r--r-- root/root 0 2010-07-20 20:37 install/postinstall.sh root@atlas /tmp #tar -C /tmp -xvzf powerdown-1.02-noarch-unRAID.tar.gz install/postinstall.sh install/postinstall.sh root@atlas /tmp #ls -l /tmp/install/postinstall.sh -rw-r--r-- 1 root root 0 Jul 20 20:37 /tmp/install/postinstall.sh root@atlas /tmp #chmod u+x /tmp/install/postinstall.sh root@atlas /tmp #/tmp/install/postinstall.sh In any case advanced package installation would have to handle the preinstall/postinstall. Just be aware of it. I'm not fond of advanced scriptlets in the .conf file past a basic install line. The other choice is to consider something how RPM does it with blocks. Instead of doing %pre do something like (but I don't know if this is possible without VAR=VALUE) [preinstall] #!/bin/sh mv /var/spool /var/spool.d mkdir /var/spool mount -t tmpfs /var/spool [postinstall] #!/bin/sh echo "to: " ... .. exit 0 OK you have the picture. Had I been involved with the unMENU stuff, I would have suggested this route along time ago.
July 21, 201015 yr Author There is no reason we can't accommodate pre/post or any other type of script when needed, but at the same time work with standard, unmodded Slackware packages from conventional package sources. Part of the problem is that we, the community, can do a package manager with a lot of bells and whistles.... but how do we get those smarts (pre/post scripts, etc) into stock unRAID? Have unRAID call our script and "trust us" or have unRAID parse and process the stuff? Starting out with plain .tgz package files for now, gets us started and we can see where it leads.
July 21, 201015 yr I only present this for example. That looks like what a SlackBuild script is for. Combine that with a 2 step package structure and it could be done. Granted it's maybe not as straight forward, but it seems simple to me. The first package could be rooted into '/tmp/packagename/'. Then the install/doinst.sh would do the work or invoke an included SlackBuild script. The last instruction of that script would run installpkg on the generated package file.
July 21, 201015 yr There is no reason we can't accommodate pre/post or any other type of script when needed, but at the same time work with standard, unmodded Slackware packages from conventional package sources. Part of the problem is that we, the community, can do a package manager with a lot of bells and whistles.... but how do we get those smarts (pre/post scripts, etc) into stock unRAID? Have unRAID call our script and "trust us" or have unRAID parse and process the stuff? Starting out with plain .tgz package files for now, gets us started and we can see where it leads. Actually I'm pretty self supporting. I've been mentioning it because of the unmenu conf package install lines. It's a method for people to add to an existing slackware binary distribution without having to rebuild it from scratch.
July 21, 201015 yr I only present this for example. That looks like what a SlackBuild script is for. Combine that with a 2 step package structure and it could be done. Granted it's maybe not as straight forward, but it seems simple to me. The first package could be rooted into '/tmp/packagename/'. Then the install/doinst.sh would do the work or invoke an included SlackBuild script. The last instruction of that script would run installpkg on the generated package file. I've dealt with allot of slackbuilds and have built allot of them too. sometimes it's easier to find a binary slackware package then the source to rebuild it. So I gave a demo of how to include pre/post scripts into a binary package. This solves the multi line conf script. (unless we want to keep going down that road). As an afterthought, forgive me Brit, I might not be grasping exactly what you are trying to explain. If I have a binary slackware package I've downloaded, and I need to doctor it up with pre/post steps. do I replace the doinst, or add pre/post to the downloaded package. My preference is to add something to unmodified packages, but then I might need to incorporate those mods for simplicity. I might be missing something.
July 21, 201015 yr How would you define multiple executable lines in the .ini file? Don't know if you can. closest would be an array, but you would still need to be able to deal with all sorts of single and double-quotes and square brackets in the scripts. Might be a reason to write our own class to parse the .ini files.
July 21, 201015 yr I've dealt with allot of slackbuilds and have built allot of them too. sometimes it's easier to find a binary slackware package then the source to rebuild it. And some times you have no choice but to compile. I wish I did not need to compile anything, but the pre-compiled packages are not to be found, or, they did not include a critical item in their config when they did the compile. I have never been able to find the ssmtp package with the SSL libraries configured. Took me a while to figure out that even though I was asking in its ssmtp.conf file for a TLS session with the mail host it was ignoring those lines in the .conf file. This solves the multi line conf script. (unless we want to keep going down that road). You will need to have something with multiple lines... What are you suggesting? As an afterthought, forgive me Brit, I might not be grasping exactly what you are trying to explain. If I have a binary slackware package I've downloaded, and I need to doctor it up with pre/post steps. do I replace the doinst, or add pre/post to the downloaded package. My preference is to add something to unmodified packages, but then I might need to incorporate those mods for simplicity. I might be missing something. Good questions. Here is one example.... A printer driver is available in source code on sourceforge in a p910nd-0.93.tar.bz2 file. Prior to compiling it, I need to make a tiny patch to it so it will return a version string when invoked with the -v option and not start a second instance of itself. (it is a bug) I have no desire to store a patched version. I can download the source from sourceforge, un-bzip it, edit it with "sed", and compile it. after compiling it, it is invoked as a daemon process. Prior to being invoked with new values, any existing daemon processes are terminated. The install lines look like this: #UNMENU_RELEASE $Revision$ $Date$ PACKAGE_NAME p910nd Shared Printer driver PACKAGE_DESCR This package will allow you to share a printer hooked up to your unRAID machine. PACKAGE_DESCR If using this package with unRAID 4.4.x then you will need a printer hooked up via PACKAGE_DESCR the parallel port on your unRAID server. 4.4.x does not include USB printer support. PACKAGE_DESCR If you are using unRAID 4.5.x then you can use either the parallel or usb port PACKAGE_DESCR <br/><b>NOTE:</b> Please see <a href="http://lime-technology.com/forum/index.php?topic=2888.0">this thread</a> PACKAGE_DESCR for an idea on what port needs to be set for your printer. PACKAGE_DESCR <br><br>p910nd implements the port 9100 network printer protocol which simply PACKAGE_DESCR copies any incoming data on the port to the printer (and in the reverse PACKAGE_DESCR direction, if bidirectional mode is selected). Both parallel and USB PACKAGE_DESCR printers are supported. This protocol was used in HP's printers and is PACKAGE_DESCR called JetDirect (probably TM). p910nd is particularly useful for PACKAGE_DESCR diskless hosts and embedded devices because it does not require any disk PACKAGE_DESCR space for spooling as this is done at the sending host. PACKAGE_DESCR <br><br>Since this printer driver is distributed as source code, you will need to first install the "gcc" compiler package. PACKAGE_DESCR If on unRAID 4.5.5 or earlier, "pbzip2" must also be installed. When you press the "Install" button, the p910nd driver will be compiled for you and installed as requested. PACKAGE_DESCR The compile step only needs to be done once, so it is not necessary to re-install the compiler or bzip2 every time you reboot. PACKAGE_DESCR <br><br>If desired, this package will optionally install /etc/rc.d/unraid.d/rc.p910nd, a script designed to facilitate the start and stop PACKAGE_DESCR of the printer server daemon.<br> PACKAGE_DESCR To stop the service, type:<br> <b>/etc/rc.d/unraid.d/rc.p910nd stop</b> PACKAGE_DESCR <br> To start it, type:<br> <b>/etc/rc.d/unraid.d/rc.p910nd start</b> # the p910nd package PACKAGE_URL http://downloads.sourceforge.net/p910nd/p910nd-0.93.tar.bz2 PACKAGE_FILE p910nd-0.93.tar.bz2 PACKAGE_MD5 f668eace7f424953c3aa48afcb34c62b PACKAGE_INSTALLED /usr/sbin/p910nd PACKAGE_DEPENDENCIES bzip2, gcc compiler, make. PACKAGE_VARIABLE Printer port (usb0, lp0)||vPort=lp0||Enter the port the printer is connected to. Valid values are <b>lp0</b> <b>usb0</b>, etc. PACKAGE_VARIABLE Bi-Directional Mode? (YES/NO)||vPrinterMode=YES||If set to "YES" Bi-Directional Mode will be used when communicating with the printer. PACKAGE_VARIABLE Install optional "rc" script? (YES/NO)||vRC_Script=NO||If set to "YES" /etc/rc.d/unraid.d/rc.p910nd will be installed. It may be used to start and stop the printer service when the array is started and stopped as described above. # a directory needed for p910nd lockfile is created if it does not exist. PACKAGE_INSTALLATION [ ! -d /var/log/subsys ] && mkdir /var/log/subsys # terminate any existing daemon process PACKAGE_INSTALLATION [ -f /var/run/p9100d.pid ] && kill `cat /var/run/p9100d.pid` 2>/dev/null PACKAGE_INSTALLATION [ -f /var/run/p9101d.pid ] && kill `cat /var/run/p9101d.pid` 2>/dev/null PACKAGE_INSTALLATION [ -f /var/run/p9102d.pid ] && kill `cat /var/run/p9102d.pid` 2>/dev/null PACKAGE_INSTALLATION [ -f /var/run/p9103d.pid ] && kill `cat /var/run/p9103d.pid` 2>/dev/null PACKAGE_INSTALLATION [ -f /var/run/p9104d.pid ] && kill `cat /var/run/p9104d.pid` 2>/dev/null PACKAGE_INSTALLATION [ -f /var/run/p9105d.pid ] && kill `cat /var/run/p9105d.pid` 2>/dev/null # compile the p910nd package so you can set it up PACKAGE_INSTALLATION if [ ! -d p910nd-0.93 ]; then PACKAGE_INSTALLATION if [ ! -x /usr/bin/bzip2 ]; then PACKAGE_INSTALLATION test ! -f /usr/bin/pbzip2 && echo "pbzip2 has not been installed. Shared printer package compile is not possible" PACKAGE_INSTALLATION test ! -f /usr/bin/pbzip2 && exit PACKAGE_INSTALLATION fi PACKAGE_INSTALLATION test ! -f /usr/bin/cc && echo "The C compiler has not been installed. Shared printer package compile is not possible" PACKAGE_INSTALLATION test ! -f /usr/bin/cc && exit PACKAGE_INSTALLATION if [ -x /usr/bin/bzip2 ]; then PACKAGE_INSTALLATION tar --no-same-owner -xvf p910nd-0.93.tar.bz2 PACKAGE_INSTALLATION else PACKAGE_INSTALLATION tar --use-compress-prog=pbzip2 --no-same-owner -xvf p910nd-0.93.tar.bz2 PACKAGE_INSTALLATION fi # apply tiny patch to allow version option to correctly exit. PACKAGE_INSTALLATION sed -i "s/\(show_version()\);$/\\1; return(2);/" p910nd-0.93/p910nd.c PACKAGE_INSTALLATION fi PACKAGE_INSTALLATION if [ ! -x p910nd-0.93/p910nd ]; then PACKAGE_INSTALLATION ( cd p910nd-0.93; make; ) PACKAGE_INSTALLATION test ! -x p910nd-0.93/p910nd && echo "Shared printer package compile failed. Install aborted" PACKAGE_INSTALLATION test ! -x p910nd-0.93/p910nd && exit PACKAGE_INSTALLATION fi PACKAGE_INSTALLATION cp p910nd-0.93/p910nd /usr/sbin/p910nd # create unraid.d directory if it does not exist for local rc. scripts. PACKAGE_INSTALLATION [ ! -d /etc/rc.d/unraid.d ] && mkdir /etc/rc.d/unraid.d #install /etc/rc.d/unraid.d/rc.p910nd to allow clean start and stop of service PACKAGE_INSTALLATION if [ "${vPrinterMode:-NO}" = "YES" ]; then PACKAGE_INSTALLATION bidirectional_flag="-b" PACKAGE_INSTALLATION else PACKAGE_INSTALLATION bidirectional_flag="" PACKAGE_INSTALLATION fi PACKAGE_INSTALLATION PACKAGE_INSTALLATION if [ "${vRC_Script:-NO}" = "YES" ]; then PACKAGE_INSTALLATION echo 'case $1 in' >/etc/rc.d/unraid.d/rc.p910nd PACKAGE_INSTALLATION echo "start)" >>/etc/rc.d/unraid.d/rc.p910nd PACKAGE_INSTALLATION echo "if [ ! -d /var/log/subsys ]; then" >> /etc/rc.d/unraid.d/rc.p910nd PACKAGE_INSTALLATION echo " mkdir /var/log/subsys" >> /etc/rc.d/unraid.d/rc.p910nd PACKAGE_INSTALLATION echo "fi" >> /etc/rc.d/unraid.d/rc.p910nd PACKAGE_INSTALLATION echo "/usr/sbin/p910nd -f /dev/${vPort:-lp0} $bidirectional_flag" >>/etc/rc.d/unraid.d/rc.p910nd PACKAGE_INSTALLATION echo ";;" >>/etc/rc.d/unraid.d/rc.p910nd PACKAGE_INSTALLATION echo "stop)" >>/etc/rc.d/unraid.d/rc.p910nd PACKAGE_INSTALLATION echo '[ -f /var/run/p9100d.pid ] && kill `cat /var/run/p9100d.pid` 2>/dev/null' >>/etc/rc.d/unraid.d/rc.p910nd PACKAGE_INSTALLATION echo '[ -f /var/run/p9101d.pid ] && kill `cat /var/run/p9101d.pid` 2>/dev/null' >>/etc/rc.d/unraid.d/rc.p910nd PACKAGE_INSTALLATION echo '[ -f /var/run/p9102d.pid ] && kill `cat /var/run/p9102d.pid` 2>/dev/null' >>/etc/rc.d/unraid.d/rc.p910nd PACKAGE_INSTALLATION echo '[ -f /var/run/p9103d.pid ] && kill `cat /var/run/p9103d.pid` 2>/dev/null' >>/etc/rc.d/unraid.d/rc.p910nd PACKAGE_INSTALLATION echo '[ -f /var/run/p9104d.pid ] && kill `cat /var/run/p9104d.pid` 2>/dev/null' >>/etc/rc.d/unraid.d/rc.p910nd PACKAGE_INSTALLATION echo '[ -f /var/run/p9105d.pid ] && kill `cat /var/run/p9105d.pid` 2>/dev/nulL' >>/etc/rc.d/unraid.d/rc.p910nd PACKAGE_INSTALLATION echo ";;" >>/etc/rc.d/unraid.d/rc.p910nd PACKAGE_INSTALLATION echo "esac" >>/etc/rc.d/unraid.d/rc.p910nd PACKAGE_INSTALLATION chmod +x /etc/rc.d/unraid.d/rc.p910nd PACKAGE_INSTALLATION else PACKAGE_INSTALLATION test -f /etc/rc.d/unraid.d/rc.p910nd && rm /etc/rc.d/unraid.d/rc.p910nd PACKAGE_INSTALLATION fi # start the daemon process PACKAGE_INSTALLATION /usr/sbin/p910nd -f /dev/${vPort:-lp0} $bidirectional_flag PACKAGE_INSTALLATION ps -ef | grep p910[0-5] | grep -v grep PACKAGE_VERSION_TEST /usr/sbin/p910nd -v | awk '{print $3}' PACKAGE_VERSION_STRING 0.93 PACKAGE_MEMORY_USAGE light
July 21, 201015 yr Author I wanted to emphasis simplicity, since I considered unRAID needed to handle packages, and I wanted to minimize having to put more work on Tom. But how about bootstrapping the package manager instead of having unRAID handle the sophisticated packages. Have unRAID events work like Slackware rc.d, and run all +x scripts in some directories like /boot/eventscripts/boot /boot/eventscripts/start /boot/eventscripts/stop /boot/eventscripts/shutdown Continue to load all the .tgz files in /boot/extra. Consider /boot/extra the place to put “bootstrap” applications, like a package manager. This directory uses very simple management using the discussed “.disabled” technique with optional .ini files. (and of course, people can put regular Slackware packages there too, and not use the community package manager.) The package manager is a pure unRAID app, so it is not being downloaded from a Slackware repository. So we can put all the smarts we want into the doinst script. It should not need a preinstall script, since it will only run at boot, and we will have authored it ourselves, so no patching should be needed like with some stock Slackware packages. It will add a package manager script to each event and the package manager takes over the initialization of packages in: /boot/packages This frees up Tom from having to deal with changes in how the community handles our packages. I still want to start out with just .tgz files and .ini files, but we can ramp up with more smarts more quickly, since we won’t have to bother Tom. I still think "safe mode" should disable all package installs and event callouts. .ini file can have: preinstall=<script> install=<script> postinstall=<script> boot=<script> start=<script> stop=<script> suhtdown=<script> Of course, if the dev wants to make one script with parameters, then it could look like this boot=abc_control.sh boot start=abc_control.sh start stop=abc_control.sh stop suhtdown=abc_control.sh shutdown
July 21, 201015 yr Here is one example.... A printer driver is available in source code on sourceforge in a p910nd-0.93.tar.bz2 file. Prior to compiling it, I need to make a tiny patch to it so it will return a version string when invoked with the -v option and not start a second instance of itself. (it is a bug) I have no desire to store a patched version. I can download the source from sourceforge, un-bzip it, edit it with "sed", and compile it. after compiling it, it is invoked as a daemon process. Prior to being invoked with new values, any existing daemon processes are terminated. The install lines look like this: ... My first thought. That does not belong there. That belongs as a p910nd.SlackBuild script. The slackbuilds commonly download source, patch, sed, compile, package. >> Prior to being invoked with new values, any existing daemon processes are terminated. This belongs in the rc script. The SSMTP with SSL, should also be a binary built slackware package. A new slackware package. It seems like the unmenu package manager also compensates by being a mini build environment. Frankly, I do not believe it should be there. I have not seen that in any distro I've worked with. The slackbuild was the first one I saw that may not include the source, but would do a wget to grab it. if you really wanted to do it that way, I would rather see the package installation do a wget to a slackbuild then build the specific binary locally if need be. Seeing all those customized build and install lines made my head spin. It's cool that it can, but I'm not sure it should. In dealing with RPMS we have SRPMS with the source and spec file and RPMs as the binary install. In dealing with Slackware we have source directories with a few slackware files and a binary install. I do not know how debian does it. I would like to hear how it works.
July 21, 201015 yr I still want to start out with just .tgz files and .ini files, but we can ramp up with more smarts more quickly, since we won’t have to bother Tom. I'm OK with this. I'm not fond of a successive series of lines to a complex environment building script.
July 21, 201015 yr how about bootstrapping the package manager instead of having unRAID handle the sophisticated packages. Good. Have unRAID events work like Slackware rc.d, and run all +x scripts in some directories like /boot/eventscripts/boot /boot/eventscripts/start /boot/eventscripts/stop /boot/eventscripts/shutdown Good, but I don't want emhttp to do the directory traversal and running of the scripts. 4 call outs to a user/community script(s). That script can traverse whatever directory structure we devise and do the subordinate execution. I still think "safe mode" should disable all package installs and event callouts. Agreed, we can look at the exported Variable CMDLINE and grep for safe. The main call out scripts can then just exit. We can source one main config/callout.cfg file for definitions. options are numerous.
July 21, 201015 yr Author I'm not fond of a successive series of lines to a complex environment building script. Neither am I. Here what I see: You can use a plain .tgz file from a standard Slackware package repository, unmodified and it will create a stub .ini for it, and run installpkg. Or you can use a .zip file, and the zip has: - a plain .tgz file from a standard Slackware package repository, unmodified. - a .ini file - the script files that are identified in the .ini file The package manager will: - extract the .ini from the zip and leave it extracted (have to handle when to overwrite/update). - extract scripts from the .zip and run them as needed (preinstall, postinstall, etc., one which will probably extract the .tgz file and run installpkg on it) This lets you maintain all the patches to a standard Slackware .tgz file even if the .tgz itself is upgraded. Just put the newer .tgz file in the zip. We could even eventually support pure .zip files with embedded paths w/o a .tgz in it.
July 21, 201015 yr Neither am I. Here what I see:... We are thinking alike here with a higher level package, the slackware package and support scripts. My only question is, why zip? unRAID does not have info zip installed by default. What about just using the .tgz file and inspecting the directory, extracting what is needed and when. That's what I was eluding to in my demo below for the pre/post scripts. If someone wanted to build a larger suite in one package, they now have that ability to include one or more slackware binary or source packages (g'fbid) and manipulate them. I'm sure you have a good reason, I just wanted to understand.
July 21, 201015 yr Author Good, but I don't want emhttp to do the directory traversal and running of the scripts. Why not? If all unRAID does is call one script, then the plugin manager has to modify that script to insert itself. Any other applications that want to hook into the events have to also modify that script. A bug in that modification can hose the other apps that have hooked in. My only question is, why zip? Ease of use ... could be rar .... could be tar. Joe seems to want to make it friendly to new devs, who are likely coming from the Windows world. unRAID does not have info zip installed by default. It will be included in the package manager! What about just using the .tgz file and inspecting the directory, extracting what is needed and when. I want to leave the .tgz file alone... so if you have say dmidecode-2.9-i486-1mfb.tgz and have tweaked the pre/post script, and a new version of dmidecode comes out, all you have to do is repackage your zip with the newer dmidecode .tgz file.
July 21, 201015 yr Good, but I don't want emhttp to do the directory traversal and running of the scripts. Why not? If all unRAID does is call one script, then the plugin manager has to modify that script to insert itself. Any other applications that want to hook into the events have to also modify that script. A bug in that modification can hose the other apps that have hooked in. Why not? Lets consider what init and inittab do. 0:0:wait:/etc/rc.d/rc 0 l1:1:wait:/etc/rc.d/rc 1 l2:2:wait:/etc/rc.d/rc 2 l3:3:wait:/etc/rc.d/rc 3 l4:4:wait:/etc/rc.d/rc 4 l5:5:wait:/etc/rc.d/rc 5 l6:6:wait:/etc/rc.d/rc 6 Inittab calls rc with a parm. rc uses the parm to traverse an rcN.d directory and run each successive script with start/stop. In our world we could have one rc script or 4 rc(runlevel) scripts which traverse the directory and run the successive scripts. This alleviates limetech/emhttp from having to read the directory, search for executables and run them. We do not have to do the slackware thing by adding to one script. The high level script's job is to traverse the named directory and run each script. This is how I handle it in my go script. I want to leave the .tgz file alone... so if you have say dmidecode-2.9-i486-1mfb.tgz and have tweaked the pre/post script, and a new version of dmidecode comes out, all you have to do is repackage your zip with the newer dmidecode .tgz file. Or repackage the higher level unRAID dmidecode.tgz file that is now in a new unRAID package format. It doesn't seem cohesive to repackage a slackware binary.tgz file into a .zip file with the support files when you have the tools with tar already there. I'm not saying the slackware.tgz package has to be added. Just encapsulate it the same way. Frankly, it could just be another slackware package with a community driver as install/doinst.sh. which happens to include the pre/post/build whatever in the install directory. The community written doinst.sh could be smart enough to grab what it needs form the tgz or from the extracted directory. oh me head spins. I actually don't see myself going down the road this way. If I really had to do something advanced, I would just step up and create a slightly more updated/advanced slackware.tgz. It's too much to accommodate. Let me think about it s'more.
July 21, 201015 yr Author I'm not aware if you can easily replace a file in a .tgz archive. AFAIK, you have to expand it, do the replace, and retar it. Whereas zip and rar can replace a file in the archive with a newer version easily on the fly. Like I said, I was trying to accommodate Joe's concern for devs coming from Windows. I can make it work just as easily on an enhanced .tgz file as a .zip file. Plus if you leave it with a .tgz extension, you run the risk of having installpkg run against it instead of it be handled by our package manager.... so the scripting will not be done.
July 21, 201015 yr Author This alleviates limetech/emhttp from having to read the directory, search for executables and run them. Is this right? .... you want emhttp to call one script, and that script traverses the directory for the event and runs the +x scripts... is that right? That was what I meant... emhttp runs the single script for the event, and that script does the traversals... so unRAID (but not emhttp) is doing the traversals.
July 21, 201015 yr I'm not aware if you can easily replace a file in a .tgz archive. AFAIK, you have to expand it, do the replace, and retar it. Whereas zip and rar can replace a file in the archive with a newer version easily on the fly. Like I said, I was trying to accommodate Joe's concern for devs coming from Windows. I can make it work just as easily on an enhanced .tgz file as a .zip file. Plus if you leave it with a .tgz extension, you run the risk of having installpkg run against it instead of it be handled by our package manager.... so the scripting will not be done. -r, --append append files to the end of an archive -u, --update only append files that are newer than copy in archive I'll have to play with it. >>> Plus if you leave it with a .tgz extension, you run the risk of having installpkg run against it instead of it be handled by our package manager.... In thinking out loud. A .tgz contains the binary tgz (or source tgz) slackware file as distributed. There are additional files php.ini, preinstall.sh postinstall.sh, etc, etc. There is a community written doinst.sh. So these files get packaged together. Now if it were to be processed with installpkg it would extract these files somewhere. run the install/doinst.sh which could then, 1. process the .ini file. 2. run the preinstall.sh. 3. Run installpkg on the included tgz file. 4. run the postinstall.sh 5. Install any unraid run level scripts. 6. cleanup itself. It's an encapsulated slackware package into the unRAID package manager format. I'll have to play with this s'more.
July 21, 201015 yr This alleviates limetech/emhttp from having to read the directory, search for executables and run them. Is this right? .... you want emhttp to call one script, and that script traverses the directory for the event and runs the +x scripts... is that right? That was what I meant... emhttp runs the single script for the event, and that script does the traversals... so unRAID (but not emhttp) is doing the traversals. That is what I meant. The words did not read that way for a moment. Perhaps I am tired. Off to bed I go, to dream more of the unDREAM.
July 21, 201015 yr Author In thinking out loud. A .tgz contains the binary tgz (or source tgz) slackware file as distributed. There are additional files php.ini, preinstall.sh postinstall.sh, etc, etc. There is a community written doinst.sh. OK.. A .tgz inside a .tgz... I though you meant add the extra unRAID-specific stuff to the original .tgz.
July 21, 201015 yr In thinking out loud. A .tgz contains the binary tgz (or source tgz) slackware file as distributed. There are additional files php.ini, preinstall.sh postinstall.sh, etc, etc. There is a community written doinst.sh. OK.. A .tgz inside a .tgz... I though you meant add the extra unRAID-specific stuff to the original .tgz. It is your intent to host the encapsulated packages somewhere? If so, that solves the issue of links to slackware packages going out-of-date, but at the cost of some disk space somewhere and affiliated bandwidth used in the download process.
July 21, 201015 yr In thinking out loud. A .tgz contains the binary tgz (or source tgz) slackware file as distributed. There are additional files php.ini, preinstall.sh postinstall.sh, etc, etc. There is a community written doinst.sh. OK.. A .tgz inside a .tgz... I though you meant add the extra unRAID-specific stuff to the original .tgz. It is your intent to host the encapsulated packages somewhere? If so, that solves the issue of links to slackware packages going out-of-date, but at the cost of some disk space somewhere and affiliated bandwidth used in the download process. The preinstall.sh could download it on demand also. I've seen a number of slackbuilds do this. Also other thoughts. What was the reason against xml? I'm starting to wonder if this would contain what is needed. There might be a way to encapsulate more information within the XML. Granted we would need some form of gui/remote/unraid tool to build the XML file. But a few fields, upload a few files and it could do all the building in PHP. There had to be a reason Thecus used it.
July 21, 201015 yr Just in following all of this I do have one comment about something mentioned earlier. I think using .zip would be a better choice for a new dev not use to a linux environment. .zip is supported natively on Windows and OS X so it would probably make it easier.
Archived
This topic is now archived and is closed to further replies.