July 20, 201015 yr Is the resistance because unmenu has assumed control of /boot/packages and/or there are temporary packages installed there? I put all my slackware "PACKAGES" into the /boot/packages directory. because they are installed by installpkg (package). If there are temporary downloaded packages then put them into /boot/packages/tmp or /boot/packages/unmenu or something more specific. i had always thought the intention of /boot/packages was to make it easier for the winfolks. Drop a slackware package into the package directory of your flash and it will be installed on the next boot. When I want to disable the installation of slackware packages I move them to some other directory in /boot/packages which prevents the installation and allows me to install them manually. winfolks can remove the package or move it. I must have missed the boat (HELP! I've fallen in and I can't swim) I remember the agreement of using /boot/packages for installing. I do not remember putting temporary packages you do not want installed in the same installation directory. If I remember correctly I suggested something like usr/share/packages and it was frowned upon suggesting I use /boot/packages. Put temporary packages under a tmp directory or under an application specific directory. example. root@atlas /boot/packages #find /boot/packages -type d /boot/packages /boot/packages/bak /boot/packages/usr /boot/packages/usr/sbin /boot/packages/links /boot/packages/specific /boot/packages/unraid_notify /boot/packages/torrent /boot/packages/torrent/bak /boot/packages/src /boot/packages/rtorrent /boot/packages/rtorrent/new /boot/packages/other /boot/packages/mail This has been my package installer ever since we started doing this. I was asked to change it to /boot/packages. #!/bin/bash if [ "${DEBUG:=0}" -gt 0 ] then set -x -v fi P=${0##*/} # basename of program R=${0%%$P} # dirname of program P=${P%.*} # strip off after last . character O=${P%_*} # Operand D=${P#${O}_} # Data (last param before _ character) PKGDIR=${PKGDIR:=/boot/packages} # Cleans ram drive root directory of unneeded files to save ram clean_ram_root() { [ -d /usr/man ] && find /usr/man -type f -exec rm {} \; [ -d /usr/man ] && find /usr/man -type l -exec rm {} \; [ -d /usr/man ] && find /usr/man -type d -empty -depth -exec rmdir {} \; [ -d /usr/lib ] && find /usr/lib -type f -name '*.a' -exec rm {} \; [ -d /usr/lib ] && find /usr/lib -type d -empty -depth -exec rmdir {} \; [ -d /usr/doc ] && find /usr/doc -type f -exec rm {} \; [ -d /usr/doc ] && find /usr/doc -type d -empty -depth -exec rmdir {} \; # [ -d /usr/src ] && find /usr/src -type f -exec rm {} \; # [ -d /usr/src ] && find /usr/src -type d -empty -depth -exec rmdir {} \; [ -d /usr/include ] && find /usr/include -type f -exec rm {} \; [ -d /usr/include ] && find /usr/include -type d -empty -depth -exec rmdir {} \; } for package in ${PKGDIR}/*.tgz $* do PKGB=${package##*/} PKGB=${PKGB%.tgz} # echo $PKGB if [ ! -f /var/log/packages/${PKGB} -o ${FORCE:=0} -gt 0 ] then echo "Installing $package" installpkg $package 2>&1 | logger -tinstallpkg -plocal7.info -i clean_ram_root else echo "$package already installed." fi done clean_ram_root I'm with bubba on this one. "slackware" packages that are not intended to be installed "don't belong in /boot/packages at all." I suggest moving Slackware packages not intended for installation to a subordinate directory or somewhere else.
July 20, 201015 yr My objection was the blanket installation of every .tgz file found in /boot/packages. That is NOT desirable. There will be plenty of packages I and others will download and install just for compiling, or for some special purpose, or for evaluation, but not need afterwords. I understand that point of view, but to me the solution for that case is that they don't belong in /boot/packages at all. I often download some on-time packages for testing or to compile a static app. But I don't put them in /boot/packages.... I keep them in /mnt/disk1/packages. You are in the minority... There are hundreds of unMENU users who have slackware packages in /boot/package simply because it was the location decided on to make it easy for them. When unMENU's package manager was developed, I used the same folder for the package.conf files, simply because it was easier on novice users to put them in the same folder with the files they were downloading. Lots of this is transparent to users, and will remain so for those not interested in scripting. Basically, we have a "data conversion" effort involved with this project that you are not yet considering. I'm guessing the ".ini" file will be the unmenu-package.conf file successor. Basically, in whatever form, that means the .ini needs to have all the features of the .conf files today. If not, then the same set of information must reside somewhere else, and having yet another file just complicates things even more. The ".ini" file is where it all should reside for any given package. Those features in the unMENU package.conf files are: Version String of the .conf file Package Title Package Description User Configuration Fields (Labels, Initial values, field descriptions, edit checks) Installation scripts, as simple as "installpkg", or as complicated as needed to compile from source and install. A flag to allow auto-update, or not, when newer versions of the package are available methods to start/stop the package if appropriate on the new emhttp "events" Dependencies, if needed Source/Package file URL(s) Source/Package file checksums (MD5) A method to know if the program is already installed (location to test for file existence) A way to test the version of the installed package The expected version "string" of the installed package. How about if the package manager defaults to saving downloaded packages as disabled when it saves them to /boot/packages? Or perhaps, if a package is found w/o a .ini file, the server disables it the first time it sees it (when running the install events), so the user has to go into the UI and enable it? Or REQUIRE a .ini file, and the UI or package mamager can create a minimal one if there is not one in the package itself. That could work... If an ini file does not exist for a .tgz, the package manager can create one, disabled by default, using installpkg as the installation method. That would also allow users to download any slackware package to the /boot/packages directory and then use the package manager UI to install/enable/disable it. I like that idea. Joe L.
July 20, 201015 yr I have a simple package manager done.... I'll make it into a package with some other utilities soon. What if we just use directories. downloaded disabled and any other "application" specific directory. Then the cool package manager can sweep the tree and use the directory name for the first level. enabled packages disabled packages (in the disabled directory). (if they are not renamed and just moved, then they can be installed manually with a button). downloaded packages (freshly downloaded waiting to be enabled or installed). application packages (with a button to "INSTALL" the slackware package).
July 20, 201015 yr You are in the minority... There are hundreds of unMENU users who have slackware packages in /boot/package simply because it was the location decided on to make it easy for them. Hi I'm WeeboTech, I'm an unRAID aholic and I don't use unMENU. I guess I'm in the minority too. I must have missed something or I would have balked at the idea of temporary packages in the /boot/packages directory from the getgo.
July 20, 201015 yr Basically, we have a "data conversion" effort involved with this project that you are not yet considering. I'm guessing the ".ini" file will be the unmenu-package.conf file successor. Basically, in whatever form, that means the .ini needs to have all the features of the .conf files today. If not, then the same set of information must reside somewhere else, and having yet another file just complicates things even more. The ".ini" file is where it all should reside for any given package. Those features in the unMENU package.conf files are: * Version String * Package Title * Package Description * User Configuration Fields (Labels, Initial values, field descriptions, edit checks) * Installation scripts, as simple as "installpkg", or as complicated as needed to compile from source and install. * A flag to allow auto-update, or not, when newer versions of the package are available * methods to start/stop the package if appropriate on the new emhttp "events" * Dependencies, if needed * Source/Package file URL(s) * Source/Package file checksums (MD5) I think the .ini file is the .conf file with a slight modification to it. I see all the same fields need to exist. I believe the .ini is because the php already supports it internally. If we had a library for the .conf file we would just support it directly. Joe, can you post a link to the most complex .conf file you may have so I can get any ideas from it.
July 20, 201015 yr I have a simple package manager done.... I'll make it into a package with some other utilities soon. Can you have this front end also query /var/log/packages looking for the package name to see if it is installed already? Perhaps the functionality to uninstall it on demand also. I like the way this looks with the sections. I would really like it to sweep a tree and present each directory as a section perhaps with Enabled Disabled Downloaded as the first three sections on top and any subsequent directories underneath.
July 20, 201015 yr Author Can you have this front end also query /var/log/packages looking for the package name to see if it is installed already? Already done. Working on running the commands out of the .ini file now, so you can do an ad-hoc install manually.
July 20, 201015 yr Author Downloaded Why? It is no different than a disabled package. Lets keep it simple. Also, why sweep a tree? Unnecessarily complicated. Let's stick to core funcationality for now, and add bells/whistles later.
July 20, 201015 yr I have a simple package manager done.... I'll make it into a package with some other utilities soon. What if we just use directories. downloaded disabled and any other "application" specific directory. Then the cool package manager can sweep the tree and use the directory name for the first level. enabled packages disabled packages (in the disabled directory). (if they are not renamed and just moved, then they can be installed manually with a button). downloaded packages (freshly downloaded waiting to be enabled or installed). application packages (with a button to "INSTALL" the slackware package). All I think you need are the three directories. Downloaded, enabled, disabled. That could work. How would you use the "application packages" directories. What I've discovered is that many of the "packages" we download need a set of "shared library" files. They are common to more than one "application" They do not need to be downloaded more than once, only need to be installed if the affiliated package that needs it is installed. those are what complicates our situation ... because we are not in a full slackware installation. That means that disabling, or enabling is not as simple as moving a single .tgz to a different directory. That same shared library .tgz might be needed by a different package. For that reason, the "package.tgz" files might all stay where the user downloaded them (why confuse the user), and the .ini files that manage them moved to the sub-directories for enabled/disabled. Comments... Hi, I'm been an unRAID aholic for nearly 5 years, and I do use unMENU. I'm not opposed to its replacement. In fact, this whole discussion might have not occurred if it did not show how unRAID could be extended. I'm opposed to the renaming/moving of the .tgz files, especially since many will not initially be managed by the 5.0 package manager. I think the .ini file might be re-named as needed, and it control the status, or, moved to a enabled/disabled sub-directory, and that control the status. If a user wants to install a new package, not from anything we create, but from a slackware package repository, we ask the user to put it in /boot/packages, and our UI can create the "default" .ini and manage the .ini as needed. Joe L.
July 20, 201015 yr I think the .ini file is the .conf file with a slight modification to it. I see all the same fields need to exist. I believe the .ini is because the php already supports it internally. If we had a library for the .conf file we would just support it directly. I agree. Joe, can you post a link to the most complex .conf file you may have so I can get any ideas from it. Sure. There are two types...Those that have downloaded files, and those that do not download anything at all, and the installation is entirely within the .conf file. Here is an example of one that has no downloaded file. There is no .tgz file involved. It has three user-configurable fields, installs a script in crontab: #UNMENU_RELEASE $Revision: 104 $ $Date: 2010-05-25 11:21:18 -0400 (Tue, 25 May 2010) $ PACKAGE_NAME unRAID Power-Down on disk overtemp PACKAGE_DESCR This package will install a cron script to power down the server when abnormally high disk temperatures are detected.<br> PACKAGE_DESCR <br><br>The script is created in /usr/local/sbin/overtemp_shutdown.sh<br> PACKAGE_DESCR It will run every 5 minutes, and shut down the unRAID array if temperature settings are exceeded.<br> PACKAGE_DESCR <b>If you have installed and configured a "mail" command on your unRAID server, you will get a warning e-mail when PACKAGE_DESCR the temperature gets above the configured warning threshold. An e-mail will also be sent if the shutdown temperature is reached and a powerown command is initiated. PACKAGE_DESCR </b><br> PACKAGE_DESCR In order to not spin up disks, only those spinning will have their temperature checked. PACKAGE_URL none PACKAGE_FILE unraid-overtemp-shutdown PACKAGE_INSTALLED /usr/local/sbin/overtemp_shutdown.sh PACKAGE_DEPENDENCIES mail, powerdown PACKAGE_VARIABLE Send warning mail to||vEMAIL_ADDR=root||Send the warning e-mail to this address. (typically "root" is already forwarded to an appropriate email) PACKAGE_VARIABLE Disk Temperature Warning Threshold||vTEMP_WARNING=50|| If an unRAID disk goes over this threshold (degrees C), a shutdown warning e-mail will be sent. PACKAGE_VARIABLE Disk Temperature Server Shutdown Threshold||vTEMP_SHUTDOWN=55|| If an unRAID disk goes over this threshold (degrees C), the server will be shut down. "/sbin/powerdown" will be use d if it is installed. PACKAGE_VERSION_TEST grep "Version:" /var/log/unRAID-overtemp-shutdown | awk '{print $2}' PACKAGE_VERSION_STRING 1.0 PACKAGE_MEMORY_USAGE Small PACKAGE_INSTALLATION [ ! -f /usr/bin/mail -a ! -f /bin/mail ] && echo "Warning: You should install 'mail' so this package can send a warning message via e-mail" PACKAGE_INSTALLATION [ ! -f /sbin/powerdown ] && echo "Warning: You should install the '/sbin/powerdown' command to permit a clean powerdown." PACKAGE_INSTALLATION echo "Version: 1.0" > /var/log/unRAID-overtemp-shutdown PACKAGE_INSTALLATION echo "vEMAIL_ADDR=\"${vEMAIL_ADDR-root}\"" >/usr/local/sbin/overtemp_shutdown.sh PACKAGE_INSTALLATION echo "vTEMP_WARNING=\"${vTEMP_WARNING-50}\"" >>/usr/local/sbin/overtemp_shutdown.sh PACKAGE_INSTALLATION echo "vTEMP_SHUTDOWN=\"${vTEMP_SHUTDOWN-55}\"" >>/usr/local/sbin/overtemp_shutdown.sh PACKAGE_INSTALLATION cat >>/usr/local/sbin/overtemp_shutdown.sh << 'THE_END_OF_SCRIPT' # For those trying to figure out what I've done here... # the leading "M" in each of the following lines in the "here" document is needed to preserve indentation. # They are removed by a "sed" command at the end of this script PACKAGE_INSTALLATION Mshutdown_flag="no" PACKAGE_INSTALLATION Mhigh_temp="0" PACKAGE_INSTALLATION Memsg="" PACKAGE_INSTALLATION Memsg_intro="" PACKAGE_INSTALLATION Mdisks=`ls --time-style='+%Y-%m-%d %I:%M%p' /dev/disk/by-id/* -Hl | grep -v plugdev | grep -v "by-id/usb" | grep -v '\-part[1-9]$' | awk '{print $9}'` PACKAGE_INSTALLATION Mfor i in $disks PACKAGE_INSTALLATION Mdo PACKAGE_INSTALLATION M hdparm -C $i 2>/dev/null | egrep "standby|unknown" >/dev/null PACKAGE_INSTALLATION M if [ "$?" != 0 ]; then PACKAGE_INSTALLATION M temp=`smartctl -d ata -A $i | grep -i temperature | sed 1q | awk '{ print $10 }'` PACKAGE_INSTALLATION M if [ "$temp" != "" ];then PACKAGE_INSTALLATION M if [ "$temp" -gt "${high_temp}" ];then PACKAGE_INSTALLATION M # Track the highest temperature we encounter PACKAGE_INSTALLATION M high_temp="${temp}" PACKAGE_INSTALLATION M fi PACKAGE_INSTALLATION M if [ "$temp" -ge "${vTEMP_WARNING-50}" ];then PACKAGE_INSTALLATION M emsg+="** disk $i temperature is ${temp}C\n$emsg.\n" PACKAGE_INSTALLATION M else PACKAGE_INSTALLATION M emsg+=" disk $i temperature is ${temp}C\n$emsg.\n" PACKAGE_INSTALLATION M fi PACKAGE_INSTALLATION M fi PACKAGE_INSTALLATION M fi PACKAGE_INSTALLATION Mdone PACKAGE_INSTALLATION Mif [ "$high_temp" != "" ];then PACKAGE_INSTALLATION M if [ "$high_temp" -gt "${vTEMP_SHUTDOWN-55}" ];then PACKAGE_INSTALLATION M emsg_intro="EMERGENCY ALERT: disk $i temperature is ${temp}C\n$emsg. Power Down Starting" PACKAGE_INSTALLATION M sSubject="EMERGENCY unRaid Overtemp Shutdown Has Started." PACKAGE_INSTALLATION M shutdown_flag="yes" PACKAGE_INSTALLATION M else PACKAGE_INSTALLATION M if [ "$high_temp" -ge "${vTEMP_WARNING-55}" ];then PACKAGE_INSTALLATION M emsg_intro="WARNING disk $i temperature is ${high_temp}C\n$emsg. Shutdown will occur if temperature goes above ${vTEMP_SHUTDOWN-50}" PACKAGE_INSTALLATION M sSubject="EMERGENCY unRaid Overtemp Shutdown Warning" PACKAGE_INSTALLATION M fi PACKAGE_INSTALLATION M fi PACKAGE_INSTALLATION Mfi PACKAGE_INSTALLATION M PACKAGE_INSTALLATION Mif [ "$emsg_intro" != "" ] PACKAGE_INSTALLATION Mthen PACKAGE_INSTALLATION M # Message Subject PACKAGE_INSTALLATION M sEcho+="Subject:$sSubject\n" PACKAGE_INSTALLATION M PACKAGE_INSTALLATION M sEcho+="Date: " PACKAGE_INSTALLATION M sEcho+=`date 2>/dev/null` PACKAGE_INSTALLATION M sEcho+="\n" PACKAGE_INSTALLATION M sEcho+="Server Name: $HOSTNAME\n" PACKAGE_INSTALLATION M sEcho+="Server IP: `ifconfig | grep 'inet addr:'| grep -v '127.0.0.1' | cut -d: -f2 | awk '{ print $1}'`\n" PACKAGE_INSTALLATION M sEcho+="$emsg\n" PACKAGE_INSTALLATION M PACKAGE_INSTALLATION M echo -e "$sEcho"|mail -s "$sSubject" ${vEMAIL_ADDR-root} PACKAGE_INSTALLATION Mfi PACKAGE_INSTALLATION Mif [ "$shutdown_flag" = "yes" ]; then PACKAGE_INSTALLATION M if [ -x /sbin/powerdown ]; then PACKAGE_INSTALLATION M /sbin/powerdown PACKAGE_INSTALLATION M else PACKAGE_INSTALLATION M if [ -x /usr/local/sbin/powerdown ]; then PACKAGE_INSTALLATION M if [ ! -f /var/log/powerdown_flag ]; then PACKAGE_INSTALLATION M /usr/local/sbin/powerdown PACKAGE_INSTALLATION M touch /var/log/powerdown_flag PACKAGE_INSTALLATION M else PACKAGE_INSTALLATION M #The prior test invoked the unRAID powerdown, but apparently it cannot, so we'll force it down. PACKAGE_INSTALLATION M /root/samba stop PACKAGE_INSTALLATION M for i in /mnt/disk* /mnt/user PACKAGE_INSTALLATION M do PACKAGE_INSTALLATION M fuser -ck $i PACKAGE_INSTALLATION M umount $i PACKAGE_INSTALLATION M done PACKAGE_INSTALLATION M /root/mdcmd stop PACKAGE_INSTALLATION M sync PACKAGE_INSTALLATION M /sbin/poweroff PACKAGE_INSTALLATION M fi PACKAGE_INSTALLATION M else PACKAGE_INSTALLATION M # Apparently no powerown command exists, try to stop the array cleanly and shut down. PACKAGE_INSTALLATION M /root/samba stop PACKAGE_INSTALLATION M for i in /mnt/disk* /mnt/user PACKAGE_INSTALLATION M do PACKAGE_INSTALLATION M fuser -ck $i PACKAGE_INSTALLATION M umount $i PACKAGE_INSTALLATION M done PACKAGE_INSTALLATION M /root/mdcmd stop PACKAGE_INSTALLATION M sync PACKAGE_INSTALLATION M /sbin/poweroff PACKAGE_INSTALLATION M fi PACKAGE_INSTALLATION M fi PACKAGE_INSTALLATION Mfi PACKAGE_INSTALLATION THE_END_OF_SCRIPT PACKAGE_INSTALLATION sed -i "s/^M//" /usr/local/sbin/overtemp_shutdown.sh PACKAGE_INSTALLATION chmod +x /usr/local/sbin/overtemp_shutdown.sh PACKAGE_INSTALLATION crontab -l >/tmp/crontab PACKAGE_INSTALLATION grep -q "overtemp_shutdown.sh" /tmp/crontab 1>/dev/null 2>&1 PACKAGE_INSTALLATION if [ "$?" = "1" ] PACKAGE_INSTALLATION then PACKAGE_INSTALLATION crontab -l | egrep -v "shutdown server if disk temperatures get too high|overtemp_shutdown.sh" >/tmp/crontab PACKAGE_INSTALLATION echo "# shutdown server if disk temperatures get too high:" >>/tmp/crontab PACKAGE_INSTALLATION echo "*/5 * * * * /usr/local/sbin/overtemp_shutdown.sh 1>/dev/null 2>&1" >>/tmp/crontab PACKAGE_INSTALLATION cp /tmp/crontab /var/spool/cron/crontabs/root- PACKAGE_INSTALLATION crontab /tmp/crontab PACKAGE_INSTALLATION fi I'll put the next example in the next post... Too big to fit here Joe L.
July 20, 201015 yr Here is the second example... Prostuff1 has been working on it. It is able to compile ffmpeg for use with the airVideo server. PACKAGE_NAME AirVideo PACKAGE_DESCR <u>Video Streaming</u><br/>Air Video can stream videos in almost any format to your iPhone and iPod touch. PACKAGE_DESCR You don't need to copy your videos to the device just to watch them.<br/><u>Live Conversion</u><br/>If the PACKAGE_DESCR videos in your collection are not in format supported by iPhone, Air Video will convert them on fly*. You PACKAGE_DESCR don't need to wait until the entire video is converted. You can start watching it almost immediately! PACKAGE_DESCR <i>* Live Conversion requires iPhone or iPod touch with firmware 3.0 and a sufficiently powerful computer PACKAGE_DESCR (Intel Core 2 duo or equivalent processor is recommended).</i> # the airvideo server .jar file PACKAGE_URL http://inmethod.com/air-video/download/linux/alpha3/AirVideoServerLinux.jar PACKAGE_FILE AirVideoServerLinux.jar PACKAGE_MD5 e04e16d8ce3a24dc5d35d0a3c3cc295a # the faac file PACKAGE_EXTRA_URL http://slackpack.ludost.net/packages/12.1/faac-1.26-i486-1gds.tgz PACKAGE_EXTRA_FILE faac-1.26-i486-1gds.tgz PACKAGE_EXTRA_MD5 b2076c450fffca386a213144b6fcdb0c # the faad2 file PACKAGE_EXTRA_URL http://slackpack.ludost.net/packages/12.1/faad2-2.6.1-i486-2gds.tgz PACKAGE_EXTRA_FILE faad2-2.6.1-i486-2gds.tgz PACKAGE_EXTRA_MD5 303562055b4c8d67cb24cf751acdf04b # the git-core file PACKAGE_EXTRA_URL http://lp.slackwaresupport.com/Slackware-10.1/Console/git-core/git-core-0.99.6-i486-1mik.tgz PACKAGE_EXTRA_FILE git-core-0.99.6-i486-1mik.tgz PACKAGE_EXTRA_MD5 f88e1beee14cbd3b5c475a1dff8935b2 # the lame file PACKAGE_EXTRA_URL http://slackpack.ludost.net/packages/12.1/lame-3.98.2-i486-1gds.tgz PACKAGE_EXTRA_FILE lame-3.98.2-i486-1gds.tgz PACKAGE_EXTRA_MD5 55deced6c5ecd9836b3bebf49f8579e4 # the mpeg file PACKAGE_EXTRA_URL http://lp.slackwaresupport.com/Slackware-11.0/X11/mpeg4ip/mpeg4ip-1.5.0.1-i486-1ahl.tgz PACKAGE_EXTRA_FILE mpeg4ip-1.5.0.1-i486-1ahl.tgz PACKAGE_EXTRA_MD5 2b50c235deb0236e59e5d7200acf0cea # the xvidcore file PACKAGE_EXTRA_URL http://repository.slacky.eu/slackware-12.1/multimedia/xvidcore/1.2.1/xvidcore-1.2.1-i486-1sl.tgz PACKAGE_EXTRA_FILE xvidcore-1.2.1-i486-1sl.tgz PACKAGE_EXTRA_MD5 3ea278d2ced5dd0afabd54a62bf0e043 # the yasm file PACKAGE_EXTRA_URL http://repository.slacky.eu/slackware-12.1/development/yasm/0.7.2/yasm-0.7.2-i486-1sl.tgz PACKAGE_EXTRA_FILE yasm-0.7.2-i486-1sl.tgz PACKAGE_EXTRA_MD5 df5df2bf568bb05990c1f0daa7e804eb # the jam file PACKAGE_EXTRA_URL http://repository.slacky.eu/slackware-12.1/development/jam/2.5/jam-2.5-i486-2gal.tgz PACKAGE_EXTRA_FILE jam-2.5-i486-2gal.tgz PACKAGE_EXTRA_MD5 096ad8c4f82e40f35bb7e000749d7175 # the x264 file PACKAGE_EXTRA_URL http://connie.slackware.com/~alien/slackbuilds/x264/pkg/13.0/x264-20100425-i486-1alien.tgz PACKAGE_EXTRA_FILE x264-20100425-i486-1alien.tgz PACKAGE_EXTRA_MD5 9868016da0904cbccbdd76cc86146d4c # the libX11 file PACKAGE_EXTRA_URL http://slackware.oregonstate.edu/slackware-12.2/slackware/x/libX11-1.1.5-i486-1.tgz PACKAGE_EXTRA_FILE libX11-1.1.5-i486-1.tgz PACKAGE_EXTRA_MD5 ffddc89e6711aa6a91ac0c4855af7789 # the libXcb file PACKAGE_EXTRA_URL http://linuxpackages.cs.utah.edu//Slackware-11.0/X11/libxcb/libxcb-1.0-i486-1ced.tgz PACKAGE_EXTRA_FILE libxcb-1.0-i486-1ced.tgz PACKAGE_EXTRA_MD5 1a7be0f71dc1cd0939e986a580b56d76 # the libXau file PACKAGE_EXTRA_URL http://slackware.oregonstate.edu/slackware-12.2/slackware/x/libXau-1.0.4-i486-1.tgz PACKAGE_EXTRA_FILE libXau-1.0.4-i486-1.tgz PACKAGE_EXTRA_MD5 8f978d7e6dd297e7f26dc0e123eaced4 # the ffmpeg for airvideo PACKAGE_EXTRA_URL http://www.inmethod.com/air-video/download/ffmpeg-for-2.2.5.tar.bz2 PACKAGE_EXTRA_FILE ffmpeg-for-2.2.5.tar.bz2 PACKAGE_EXTRA_MD5 1623d51b433555e08d0c2fcf1dee1b55 PACKAGE_INSTALLED /var/log/airvideo PACKAGE_DEPENDENCIES This package relies on quite a few different package. Most are installed along with this one but PACKAGE_DEPENDENCIES there are a few that need to be installed prior to this package. The JAVA JRE package that is PACKAGE_DEPENDENCIES included with unmenu should be installed first!! PACKAGE_VARIABLE password||vPassword=12345||Enter the password used to connect to the Airvideo Server PACKAGE_VARIABLE folders||vFolders=Anime:/mnt/user/Anime,Movies:/mnt/user/Movies,TV Shows:/mnt/usr/TV Shows||Enter the list of folders you would like to be visible. Note the format of the line and make sure to replicate it exactly for your sources PACKAGE_INSTALLATION installpkg "${PACKAGE_DIRECTORY}"/x264-20100425-i486-1alien.tgz PACKAGE_INSTALLATION installpkg "${PACKAGE_DIRECTORY}"/faac-1.26-i486-1gds.tgz PACKAGE_INSTALLATION installpkg "${PACKAGE_DIRECTORY}"/faad2-2.6.1-i486-2gds.tgz PACKAGE_INSTALLATION installpkg "${PACKAGE_DIRECTORY}"/xvidcore-1.2.1-i486-1sl.tgz PACKAGE_INSTALLATION installpkg "${PACKAGE_DIRECTORY}"/git-core-0.99.6-i486-1mik.tgz PACKAGE_INSTALLATION installpkg "${PACKAGE_DIRECTORY}"/jam-2.5-i486-2gal.tgz PACKAGE_INSTALLATION installpkg "${PACKAGE_DIRECTORY}"/lame-3.98.2-i486-1gds.tgz PACKAGE_INSTALLATION installpkg "${PACKAGE_DIRECTORY}"/mpeg4ip-1.5.0.1-i486-1ahl.tgz PACKAGE_INSTALLATION installpkg "${PACKAGE_DIRECTORY}"/yasm-0.7.2-i486-1sl.tgz PACKAGE_INSTALLATION installpkg "${PACKAGE_DIRECTORY}"/libX11-1.1.5-i486-1.tgz PACKAGE_INSTALLATION installpkg "${PACKAGE_DIRECTORY}"/libxcb-1.0-i486-1ced.tgz PACKAGE_INSTALLATION installpkg "${PACKAGE_DIRECTORY}"/libXau-1.0.4-i486-1.tgz # compile ffmpeg first. that way we have as much RAM as possible for it to succeed. PACKAGE_INSTALLATION if [ ! -d "${PACKAGE_DIRECTORY}/ffmpeg" ]; then PACKAGE_INSTALLATION test ! -f /usr/bin/bzip2 && echo "An untar program was not detected. Please install the Parallel bzip package." PACKAGE_INSTALLATION test ! -f /usr/bin/bzip2 && exit PACKAGE_INSTALLATION test ! -f /usr/bin/cc && echo "The C compiler has not been installed. ffmpeg compile not possible" PACKAGE_INSTALLATION test ! -f /usr/bin/cc && exit PACKAGE_INSTALLATION cd "${PACKAGE_DIRECTORY}"; PACKAGE_INSTALLATION if [ -f /usr/bin/bzip2 ]; then PACKAGE_INSTALLATION tar --no-same-owner -xf ffmpeg-for-2.2.5.tar.bz2; PACKAGE_INSTALLATION else PACKAGE_INSTALLATION tar --use-compress-prog=pbzip2 --no-same-owner -xf ffmpeg-for-2.2.5.tar.bz2; PACKAGE_INSTALLATION fi PACKAGE_INSTALLATION cd "${PACKAGE_DIRECTORY}/ffmpeg"; PACKAGE_INSTALLATION ./configure.orig.fixed --enable-gpl --enable-nonfree --enable-postproc --enable-pthreads --enable-libfaac --enable-libfaad --enable-libmp3lame --enable-libx264 --enable-libxvid --enable-x11grab --disable-shared --enable-static --disable-decoder=aac; make; PACKAGE_INSTALLATION fi PACKAGE_INSTALLATION test ! -f "${PACKAGE_DIRECTORY}/ffmpeg/ffmpeg" && echo "ffmpeg compile failed. install aborted" PACKAGE_INSTALLATION test ! -f "${PACKAGE_DIRECTORY}/ffmpeg/ffmpeg" && exit #install /etc/rc.d/unraid.d/rc.unraid_airvideo to allow clean start and stop of service PACKAGE_INSTALLATION [ ! -d /etc/rc.d/unraid.d ] && mkdir /etc/rc.d/unraid.d PACKAGE_INSTALLATION if [ ! -f /etc/rc.d/unraid.d/rc.unraid_airvideo ]; then PACKAGE_INSTALLATION echo 'case $1 in' >/etc/rc.d/unraid.d/rc.unraid_airvideo PACKAGE_INSTALLATION echo "start)" >>/etc/rc.d/unraid.d/rc.unraid_airvideo PACKAGE_INSTALLATION echo "cd ${PACKAGE_DIRECTORY}" >>/etc/rc.d/unraid.d/rc.unraid_airvideo PACKAGE_INSTALLATION echo "air-video-server.sh test.properties" >>/etc/rc.d/unraid.d/rc.unraid_airvideo PACKAGE_INSTALLATION echo ";;" >>/etc/rc.d/unraid.d/rc.unraid_airvideo PACKAGE_INSTALLATION echo "stop)" >>/etc/rc.d/unraid.d/rc.unraid_airvideo PACKAGE_INSTALLATION echo "if [ $(ps -ef | grep jre | awk 'NR < 2' | awk '{print$10}') == ${PACKAGE_DIRECTORY}/AirVideoServerLinux.jar ]; then" >>/etc/rc.d/unraid.d/rc.unraid_airvideo PACKAGE_INSTALLATION echo " kill $(ps -ef | grep jre | awk 'NR < 2' | awk '{print$2}');" >>/etc/rc.d/unraid.d/rc.unraid_airvideo PACKAGE_INSTALLATION echo "fi" >>/etc/rc.d/unraid.d/rc.unraid_airvideo PACKAGE_INSTALLATION echo ";;" >>/etc/rc.d/unraid.d/rc.unraid_airvideo PACKAGE_INSTALLATION echo "esac" >>/etc/rc.d/unraid.d/rc.unraid_airvideo PACKAGE_INSTALLATION chmod +x /etc/rc.d/unraid.d/rc.unraid_airvideo PACKAGE_INSTALLATION fi PACKAGE_INSTALLATION rm -f "${PACKAGE_DIRECTORY}"/test.properties PACKAGE_INSTALLATION touch "${PACKAGE_DIRECTORY}"/test.properties PACKAGE_INSTALLATION echo "path.ffmpeg = "${PACKAGE_DIRECTORY}"/ffmpeg/ffmpeg" >> /test.properties PACKAGE_INSTALLATION echo "path.mp4creator = /usr/bin/mp4creator" >> "${PACKAGE_DIRECTORY}"/test.properties PACKAGE_INSTALLATION echo "path.faac = /usr/bin/faac" >> "${PACKAGE_DIRECTORY}"/test.properties PACKAGE_INSTALLATION echo "password = passwordPlaceHolder" >> "${PACKAGE_DIRECTORY}"/test.properties PACKAGE_INSTALLATION echo "subtitles.encoding = windows-1250" >> "${PACKAGE_DIRECTORY}"/test.properties PACKAGE_INSTALLATION echo "subtitles.font = Verdana" >> "${PACKAGE_DIRECTORY}"/test.properties PACKAGE_INSTALLATION echo "folders = folderPlaceHolder" >> "${PACKAGE_DIRECTORY}"/test.properties PACKAGE_INSTALLATION sed -i s@passwordPlaceHolder@"${vPassword}"@ test.properties PACKAGE_INSTALLATION sed -i s@folderPlaceHolder@"${vFolders}"@ test.properties PACKAGE_INSTALLATION rm -rf "${PACKAGE_DIRECTORY}"/air-video-server.sh PACKAGE_INSTALLATION touch "${PACKAGE_DIRECTORY}"/air-video-server.sh PACKAGE_INSTALLATION echo "#!/bin/bash" >> "${PACKAGE_DIRECTORY}"/air-video-server.sh PACKAGE_INSTALLATION echo "" >> "${PACKAGE_DIRECTORY}"/air-video-server.sh PACKAGE_INSTALLATION echo "PROPFILE='/etc/conf.d/air-video-server'" >> "${PACKAGE_DIRECTORY}"/air-video-server.sh PACKAGE_INSTALLATION echo "LOCALPROP=\`echo ~/.air-video-server/air-video-server.properties\`" >> "${PACKAGE_DIRECTORY}"/air-video-server.sh PACKAGE_INSTALLATION echo "if [ -a \"\$1\" ]; then" >> "${PACKAGE_DIRECTORY}"/air-video-server.sh PACKAGE_INSTALLATION echo " PROPFILE=\"\$1\"" >> "${PACKAGE_DIRECTORY}"/air-video-server.sh PACKAGE_INSTALLATION echo "else" >> "${PACKAGE_DIRECTORY}"/air-video-server.sh PACKAGE_INSTALLATION echo " [ -a \"\$LOCALPROP\" ] && PROPFILE=\"\$LOCALPROP\"" >> "${PACKAGE_DIRECTORY}"/air-video-server.sh PACKAGE_INSTALLATION echo "fi" >> "${PACKAGE_DIRECTORY}"/air-video-server.sh PACKAGE_INSTALLATION echo "exec /usr/lib/jre1.6.0_11/bin/java -jar "${PACKAGE_DIRECTORY}"/AirVideoServerLinux.jar \"\$PROPFILE\"" >> "${PACKAGE_DIRECTORY}"/air-video-server.sh PACKAGE_INSTALLATION chmod +x "${PACKAGE_DIRECTORY}"/air-video-server.sh PACKAGE_INSTALLATION echo "Version: 2.2.5" > /var/log/airvideo PACKAGE_INSTALLATION cd "${PACKAGE_DIRECTORY}" PACKAGE_INSTALLATION echo "bash air-video-server.sh test.properties" | at now + 1 minute PACKAGE_VERSION_TEST grep "Version:" /var/log/airvideo | awk '{print $2}' PACKAGE_VERSION_STRING 2.2.5 PACKAGE_MEMORY_USAGE Heavy
July 20, 201015 yr And a third example, near and dear to BubbaQ's heart. It downloads, un-packs, patches three bugs,re-packs, and then installs unRAID-Web: #UNMENU_RELEASE $Revision: 7 $ $Date: 2010-03-29 23:12:23 -0400 (Mon, 29 Mar 2010) $ PACKAGE_NAME unRAID-Web PACKAGE_DESCR UnRAID-Web is a full featured web-server and php based extension to unRAID. It, like unMENU, provides many new features PACKAGE_DESCR you may use to manage an unRAID array. It also allows for "extensions" to add new functions PACKAGE_DESCR to its left-hand navigation menu.<br><br> PACKAGE_DESCR One of the extensions allows you to access most of the unMENU plug-in web-pages PACKAGE_DESCR you've already installed.<br>Another extension is <b>AjaxExplorer</b>, a full featured file browser that runs in your web-browser. PACKAGE_DESCR (login=admin, password=admin)<br><br> PACKAGE_DESCR UnRAID-Web consists of:<br> PACKAGE_DESCR - lighttpd 1.4.19 (light web server)<br> PACKAGE_DESCR - php 5.2.8<br> PACKAGE_DESCR - Gamin 0.1.9 (FAM - lighttpd dependency)<br> PACKAGE_DESCR - libxml (php dependency)<br> PACKAGE_DESCR - lighttpd and php config files on the flash (in /boot/custom/lighttpd) <br><br> PACKAGE_DESCR Several "extensions" are supplied.<br> PACKAGE_DESCR - unRAID-Web extension - written by BubbaQ<br> PACKAGE_DESCR - unMENU extension - written by Joe L.<br> PACKAGE_DESCR - Super-Shutdown extension - written by BubbaQ<br> PACKAGE_DESCR - AjaxExplorer extension<br><br> PACKAGE_DESCR When installed, the main unRAID-Web page will be present on port 89 of the unRAID server. (typically http://tower:89)<br> PACKAGE_DESCR All the installed "extensions" will be available in a left-side navigation menu.<br> PACKAGE_DESCR To access the unMENU extension without a left-nav menu, use http://tower:89/extensions/unmenu<br> PACKAGE_DESCR You do not need to have unMENU running to use unRAID-Web.<br> PACKAGE_DESCR A mini-control panel on port 2197 is available to start, stop and control the lighttpd web-server. (http://tower:2197) PACKAGE_URL http://www.tcpatools.com/bubba/unraidweb-0.1.04-i386-bubba.tgz PACKAGE_FILE unraidweb-0.1.04-i386-bubba.tgz PACKAGE_MD5 6030325176a43e4ed27dc55fc3c88111 PACKAGE_INSTALLED /var/log/unRAID-web-version PACKAGE_DEPENDENCIES none PACKAGE_INSTALLATION # since we need to fix things in three files, un-gzip/tar the files, edit them, then re-tar/gzip. PACKAGE_INSTALLATION mkdir -p /tmp/unmenuTMP PACKAGE_INSTALLATION ( cd /tmp/unmenuTMP ; gzip -dc | tar-1.13 xf - ) <unraidweb-0.1.04-i386-bubba.tgz PACKAGE_INSTALLATION # edit the index.php file to deal with not having current directoy in PATH PACKAGE_INSTALLATION sed -i "s~cmd .= ' \" . \$a->add_on . \"~cmd .= ' .\/\" . \$a->add_on . \"~" /tmp/unmenuTMP/boot/custom/lighttpd/extensions/unmenu/index.php PACKAGE_INSTALLATION sed -i "s~/boot/unmenu_final~$SCRIPT_DIRECTORY~" /tmp/unmenuTMP/boot/custom/lighttpd/extensions/unmenu/extension.conf PACKAGE_INSTALLATION sed -i "s~boot\/config~boot\/custom~" /tmp/unmenuTMP/boot/custom/lighttpd/setup/index.php PACKAGE_INSTALLATION ( cd /tmp/unmenuTMP ; tar-1.13 cf - * | gzip ) >unraidweb-fixed-0.1.04-i386-bubba.tgz PACKAGE_INSTALLATION rm -rf /tmp/unmenuTMP PACKAGE_INSTALLATION installpkg unraidweb-fixed-0.1.04-i386-bubba.tgz </dev/null 2>&1 PACKAGE_INSTALLATION echo "0.1.04" >/var/log/unRAID-web-version PACKAGE_VERSION_TEST cat /var/log/unRAID-web-version 2>/dev/null PACKAGE_VERSION_STRING 0.1.04 PACKAGE_MEMORY_USAGE large [/quote]
July 20, 201015 yr Downloaded Why? It is no different than a disabled package. Lets keep it simple. Also, why sweep a tree? Unnecessarily complicated. Let's stick to core funcationality for now, and add bells/whistles later. Trial or "temporary" packages. Something may have been downloaded by some automatic process.
July 20, 201015 yr One of the reasons I suggested using directories and symlinks was to ease management while adding what I saw as needed functionality. Most of it Joe L pointed out better than I could. Though I think one could get by with two directories and no package file renames. One directory is a repository of available packages. The other is a directory of auto-installed/enabled packages, perhaps its merely the name of the package. Perhaps the configurations could be stored in it's own directory depending on how tidy you want things. You scrape the installpkg logs of /var/log/packages to see what's installed and enabled. When you uninstall a package, you simple 'removepkg' it. When you disable the auto-install feature, you remove the package filename from the autoinstall directory (or the .autoinstall file). As Joe L mentioned dependencies I'll speak a bit about them as well. If you rename the packages or relocate them, the package manager becomes more complicated by having to search multiple locations with multiple filenames. I'll leave the discussion about reference counting dependencies and auto garbage collection upon uninstalls for later. Possibly: /boot/packages/repos - contains all the packages available /boot/packages/config - contains all the package configuration files /boot/packages/autoinstall - contains empty file named same as the package to be auto-installed. This is possibly close to how unMenu does it, but spread out across 3 directories instead of just 1 directory with the original '.t[gx]z', '.conf', and '.autoinstall' files. Apologies if this isn't exactly how unMenu does it, but I think its encompasses the basic methodology premise.
July 20, 201015 yr How would you use the "application packages" directories. The whole rtorrent suite I built required a large number of packages that I had to collect compile and present for installation. Sometimes on demand, sometimes it broke the system. It is just a way of segregating some of these files. I have 146 packages Some I want to manage and install in batches and need a clean way of doing that. For example, if I'm going to use my unRAID environment to temporarily build something, there might be a set of files that I need installed together to get this done on a temporary basis. Then I want to uninstall them. rtorrent with xml-rpc took about 13 files to build and install. This was without the webserver. With the webserver would have taken a few more.
July 20, 201015 yr From what WeeboTech posted, perhaps something to think about (later) is having package categories, not too dissimilar to how Slackware has it. This might make it tidier by having 'libraries', 'compilers', 'apps', 'services', 'tools', 'web', 'web ui', etc...
July 20, 201015 yr Now I remember why I was did not use the unmenu conf scriptlets. That can become unwieldy. It seems to also support the ability to not require a single repostory for the data. It's cool, but I also see unpackaging, the patching and repackaging. We might want to consider a new unRAID installable package/archive/zip whatever and use a methodology like slackware or Thecus does. Even RPM. Slackware has the doinst.sh which is done at installation time. Like RPM, perhaps we need a preinstall.sh to set things up this is extracted and run before the installpkg. then after extract and run a postinstall.sh Thecus modules have an enable and disable shell too. Take a look here for more ideas. http://www.onbeat.dk/thecus/index.php/N5200_Module_Development
July 20, 201015 yr Author I have to say those config file are a kludge... I understand where they came from and how they evolved, but looking at those is like looking at a 1980's era pong console compared to a ps3. Embedding a script in a config file? Horrid. The Slackware package system is far, far superior. It is simple and easy -- I can not for the life of me understand the resistance to it. It handles an install script, dependencies, descriptions, and the copying of the files. We have a greenfield.... lets not hang anchors around our neck. Add a method for designating a cluster of packages (i.e. the compiler and needed libraries) and the package manager, or hell, just any intelligent script, can process it, and installpkg the ones not already installed.
July 21, 201015 yr Embedding a script in a config file. It worked. I remember choosing not to go there. But it is a simple one file way of handling the text. It does sort of remind me of an rpm spec file, but they have the. %pre %post scriptlet blocks which are extracted and run by a shell. If we were to have a repository of package configurations how would they be downloaded? I think educating a developer and maybe extending slackware with the preinstall,postinstall scripts could help.
July 21, 201015 yr I kind of see some of the preinstall scripts as being similar to 'SlackBuild'. The resulting file can then be fed into 'installpkg'. Is this that different? That or preinstall scripts could be done by having the 'doinst.sh' script. Instead of having the packages contents ('uutf.txz') into its final location (/usr/local/lib, /usr/local/bin, /usr/lib, /usr/bin, etc), it's setup to use /tmp/*. Once installpkg is done extracting the package contents ('uutf.txz'), it kicks off 'doinst.sh' to do the preinstall steps, install the desired resources, then doing any postinstall steps. Yes it makes for more complicated doinst.sh scripts, but it works within the confines of Slackware package tools.
July 21, 201015 yr Author It worked. So did respawning awk ... but we aren't holding onto that anchor now that better tools are available.
July 21, 201015 yr I mentioned the preinstall.sh because I saw the .conf file uncompressing, patching a file, recompressing it. then letting installpkg take over. In RPM land, %pre is to set up the environment for the install, such as adding users with useradd or doing other things before the RPM is cpio'ed into place. I think this is important for some apps in RH land where the uids/gids matter and are to be set to standards. I don't know where it's needed here all the time. I don't see many people modifiying the install/doinst.sh script. I have, but this is a grey area for some. besides it might be easier to acquire the slackware package, then uncompress it Add the preinstal.sh postinstall.sh into the tar file vs modifying the doinst.sh. I know I have a number of packages/shells where I install the pkg then copy over some files from flash. If a new package comes out you would have to do the modify vs just reappending the pre/post scripts. If we took the time to show people how to do the slackware packages it might make it easier.
July 21, 201015 yr I have to say those config file are a kludge... I understand where they came from and how they evolved, but looking at those is like looking at a 1980's era pong console compared to a ps3.All I can say is the whole unMENU project is a kludge. It was not designed to be the most elegant, but the simplest for inexperienced users of unRAID to extend. It did its job fairly well. It evolved... and it did it with the tools available on unRAID. It has its own built-in version of wget. We did not get an official version of wget included in unRAID until it was established there was a need. Embedding a script in a config file? Horrid.Perhaps, and any number of packaging schemes could have been used, but almost any of them would have excluded beginning users from contributing. The learning curve is simply too great. I guess you've never used "shar" "shell" archives. An equally elegant kludge. In any case, I can write complicated code, and use the slackware package tools, and use "tar", but they serve no additional purpose, at least for what unMENU needed. I did not need to have a user download any additional file, as when unMENU was originally written I had no google.code repository for it to use to download an affiliated locally packaged script. We still have the need for a package repository for those that are developed by unRAID users vs. Slackware packages available from a slackware repository. You asked for complex examples. you got them. The Slackware package system is far, far superior. It is simple and easy -- I can not for the life of me understand the resistance to it. It handles an install script, dependencies, descriptions, and the copying of the files. For you and me, not difficult, but the overhead for a simple unMENU package file is really high. A simple package has only a few lines, like this: The whole installation is one line. #UNMENU_RELEASE $Revision: 7 $ $Date: 2010-03-29 23:12:23 -0400 (Mon, 29 Mar 2010) $ PACKAGE_NAME file - A utility to determine file type PACKAGE_DESCR This is Ian F. Darwin's 'file' utility, used to identify files. PACKAGE_URL http://slackware.cs.utah.edu/pub/slackware/slackware-12.2/slackware/a/file-4.21-i486-1.tgz PACKAGE_FILE file-4.21-i486-1.tgz PACKAGE_MD5 b97a3ae071ae458ad6c0500b287a292f PACKAGE_INSTALLED /usr/bin/file PACKAGE_DEPENDENCIES none PACKAGE_INSTALLATION installpkg file-4.21-i486-1.tgz PACKAGE_VERSION_TEST /usr/bin/file -v 2>&1 PACKAGE_VERSION_STRING file-4.21 PACKAGE_MEMORY_USAGE Light (10K to 500K) We have a greenfield.... lets not hang anchors around our neck. Add a method for designating a cluster of packages (i.e. the compiler and needed libraries) and the package manager, or hell, just any intelligent script, can process it, and installpkg the ones not already installed. No argument there, but I need to consider the existing embedded base of files in /boot/packages. I'll be converting the .conf files to .ini files (rather than writing a PHP class to interpret them directly) I'm just more aware of the issues we face when using a combination of Slackware packages and unRAID's skeletal implementation of Slackware Linux. I'm sure we can create intelligent scripts, and package them somehow, but that is exactly what exists in the PACKAGE_INSTALLATION lines of an unMENU .conf file. It is just all in one readable text file instead of in a doinst.sh script in a compressed tar file. It would have been in the doinst.sh file in a slackware package if I had used that method from the beginning, but again, it would have excluded less experienced users from participating in unMENU's evolution to explore ways to improve unRAID, and it would not have been readable text. My design goal was to make the package files readable, so they would not scare off potential contributors. In the same way, the .ini files will be readable. Do we really need the .ini file to download another file for a simple cron entry. In my opinion, that might be overkill, but as long as we have a repository, it really does not matter, except a new contributor may not have a repository available. Lots to consider... Lots to leave behind... and lots of new tools to build upon. Joe L.
July 21, 201015 yr Do we really need the .ini file to download another file for a simple cron entry. In my opinion, that might be overkill, but as long as we have a repository, it really does not matter, except a new contributor may not have a repository available. It could be a shar for all I care.. LOL I remember those all too well. They worked. It could be a zip with the .ini configuration and any other scriptlets. Actually if unmenu were in perl (or miniperl) it could have been embedded in the script too (like a pod or as _DATA_). 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. 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.
July 21, 201015 yr From what WeeboTech posted, perhaps something to think about (later) is having package categories, not too dissimilar to how Slackware has it. This might make it tidier by having 'libraries', 'compilers', 'apps', 'services', 'tools', 'web', 'web ui', etc... The package manager should have this feature... It points out we need one more item in the .ini file... the package category.
Archived
This topic is now archived and is closed to further replies.