July 20, 201015 yr Author I was looking for a solution that would let packages be installed w/o having to consult a different file (either contents or filename).... But using the ini file as the disabling key is fine if that's what you guys prefer, but what about .tgz files that have no .ini file? To disable that .tgz, you have to create a (minimal) .ini file with the .disabled suffix? That seems doable. But in that case, I'd lean towards the .ini files being in the same dir with their associated package file. Perhaps we go simple at the beginning... using ".disabled" on the .tgz files for now, and plan to add more sophisticated control via the .ini files as we get further down the field? I'm still a bit confused about the example "airVideo" ... are you saying all those .tgz files are in the .jar zip file, and to install it, you have to extract them all from the zip, and installpkg each one?
July 20, 201015 yr >> Please, do not ask me to try re-name a full set of 14 .tgz files if we wish to enable, or disable a package. There seem to be two definitions of package here. We have the slackware package which is the root of supportive constructs. We have the "managed" plugin package which contains definitions to describe a package(plugin) which would "require" one or more supportive packages. For the supportive slackware package renaming them is something I would do. Now for the plugin, you have the choice of renaming the .ini file so the plugin manager will not process it. updating a variable in the INI file STATUS=DISABLED so the plugin manager will not process it. or have the plugin manager rename the list of required support packages. You do not have to rename 14 files, The plugin support facility should handle it in one of the manners. Also, no one has to update slackware packages to include the .ini file. It's only an option and if they choose to do it that way for simplicity, then they must insure it does not overwrite an existing .ini file. I really don't see people including it. I would expect the package repository to present one for downloading to a directory hierarchy then being smart enough to download the slackware support packages or know they exist locally and are enabled for install.
July 20, 201015 yr Perhaps we go simple at the beginning... using ".disabled" on the .tgz files for now, and plan to add more sophisticated control via the .ini files as we get further down the field? This works for now.
July 20, 201015 yr I was looking for a solution that would let packages be installed w/o having to consult a different file (either contents or filename).... But using the ini file as the disabling key is fine if that's what you guys prefer, but what about .tgz files that have no .ini file? To disable that .tgz, you have to create a (minimal) .ini file with the .disabled suffix? That seems doable. But in that case, I'd lean towards the .ini files being in the same dir with their associated package file. Perhaps we go simple at the beginning... using ".disabled" on the .tgz files for now, and plan to add more sophisticated control via the .ini files as we get further down the field? I'm still a bit confused about the example "airVideo" ... are you saying all those .tgz files are in the .jar zip file, and to install it, you have to extract them all from the zip, and installpkg each one? No, those are mostly the shared library files needed to run ffmpeg, you still need the Java Run-time (another package) to run the .jar file which in turn invokes ffmpeg. I would not expect anything to automatically install every .tgz found. As I said, that is frequently not desired. (Although Tom in his latest release does have a "/boot/start" directory where every file in its installed with installpkg BEFORE emhttp is invoked.)
July 20, 201015 yr Perhaps we go simple at the beginning... using ".disabled" on the .tgz files for now, and plan to add more sophisticated control via the .ini files as we get further down the field? This works for now. No, it does not work for now. It ONLY works if you do not use /boot/packages or have no existing packages I have these, and no way do I think re-naming them is "easier for now": /boot/packages/apcupsd-3.14.3-i486-1kjz.tgz* /boot/packages/jam-2.5-i486-2gal.tgz* /boot/packages/php-5.2.8-i486-1.tgz* /boot/packages/apcupsd-3.14.8-i486-1_rlw.tgz* /boot/packages/kernel-headers-2.6.27.7_smp-x86-1.tgz* /boot/packages/powerdown-1.02-noarch-unRAID.tgz* /boot/packages/apr-1.3.3-i486-1.tgz* /boot/packages/lame-3.98.2-i486-1gds.tgz* /boot/packages/reiserfsprogs-3.6.21-i486-1.txz* /boot/packages/apr-util-1.3.4-i486-1.tgz* /boot/packages/libX11-1.1.5-i486-1.tgz* /boot/packages/ruby-1.9.1_p378-i486-1.txz* /boot/packages/binutils-2.18.50.0.9-i486-1.tgz* /boot/packages/libXau-1.0.4-i486-1.tgz* /boot/packages/rubygems-1.3.5.tgz* /boot/packages/bwm-ng-0.6-i486-2bj.tgz* /boot/packages/libxcb-1.0-i486-1ced.tgz* /boot/packages/samba-3.5.2-i486-1.txz* /boot/packages/cpio-2.5-i486-3.tgz* /boot/packages/lighttpd-1.4.19-i486-1mad.tgz* /boot/packages/samba-3.5.2.tar.xz* /boot/packages/cxxlibs-6.0.9-i486-1.tgz* /boot/packages/lssmtp_2.61.orig.tar.gz* /boot/packages/samba-3.5.3.tar.gz* /boot/packages/dmidecode-2.9-i486-1.tgz* /boot/packages/mailx-12.3-i486-1.tgz* /boot/packages/screen-4.0.3-i486-1.tgz* /boot/packages/faac-1.26-i486-1gds.tgz* /boot/packages/make-3.81-i486-1.tgz* /boot/packages/ssmtp_2.61.orig.tar.gz* /boot/packages/faad2-2.6.1-i486-2gds.tgz* /boot/packages/mc-20100206_git-i486-1.txz* /boot/packages/ssmtp_2.62.orig.tar.gz* /boot/packages/file-4.21-i486-1.tgz* /boot/packages/mpeg4ip-1.5.0.1-i486-1ahl.tgz* /boot/packages/strace-4.5.18-i486-1.txz* /boot/packages/gamin-0.1.9-i486-1.tgz* /boot/packages/neon-0.28.3-i486-1.tgz* /boot/packages/subversion-1.5.4-i486-1.tgz* /boot/packages/gc-7.1-i486-2mfb.tgz* /boot/packages/ntfs-3g-2009.4.4-i486-1.txz* /boot/packages/unraidweb-0.1.04-i386-bubba.tgz* /boot/packages/gcc-4.2.4-i486-1.tgz* /boot/packages/ntfs-3g-2010.3.6-i486-1.txz* /boot/packages/unraidweb-fixed-0.1.04-i386-bubba.tgz* /boot/packages/git-core-0.99.6-i486-1mik.tgz* /boot/packages/ntfs-3g-2010.3.6.tgz* /boot/packages/utempter-1.1.4-i486-1.tgz* /boot/packages/glibc-2.7-i486-17.tgz* /boot/packages/openssh-5.1p1-i486-1.tgz* /boot/packages/w3m-0.5.2-i486-2dd.tgz* /boot/packages/htop-0.8.3-i486-1sl.tgz* /boot/packages/openssl-0.9.8i-i486-1.tgz* /boot/packages/x264-20100425-i486-1alien.tgz* /boot/packages/iftop-0.17-i486-1kan.tgz* /boot/packages/pbzip2-1.0.4-i486-1mac.tgz* /boot/packages/xvidcore-1.2.1-i486-1sl.tgz* /boot/packages/infozip-5.52-i486-2.tgz* /boot/packages/pciutils-2.2.10-i486-2.tgz* /boot/packages/yasm-0.7.2-i486-1sl.tgz* /boot/packages/inotify-tools-3.13-i486-1.tgz* /boot/packages/perl-5.10.0-i486-1.tgz*
July 20, 201015 yr If you make the format complicated, you'll not get the contributions from those who have no clue on how to create a ".tgz" installpkg. That, I think would be a mistake. I don't profess to be one of the heavy hitters around here (i will leave that to WeeboTech, BubbaQ, and JoeL, etc) but I completely agree with the above statement. I have created a few of the unmenu packages and once i got the hang of it it was straight forward. I do not know how to create the ".tgz" or ".txz" files that could be installed so that one application is installed in a single go. Granted I probably need to go about figuring out how to do that but, just have not had the time as of yet. Unmenu has a very good setup already in place and some expanding and refining on those traits is what is needed.
July 20, 201015 yr I would not expect anything to automatically install every .tgz found. As I said, that is frequently not desired. (Although Tom in his latest release does have a "/boot/start" directory where every file in its installed with installpkg BEFORE emhttp is invoked.) This happens now with the "/boot/extra" directory. I don't see a problem with this other then it does not look for more specific files for installpkg. If it's a known api that files in a directory are operated on in a specific manner, then when it's desired people will drop files there. My wish is that it's not in the rc.local script. Rather it is in a emhttp callout "boot" event so it can be controlled, modified, logged or disabled.
July 20, 201015 yr Author So how about using the .tgz and .tgz.disabled for now, using standard .tgz slackware packages. That is the closest to the current package handling in unRAID. That way we can get the first iteration of installpkg iterations into unRAID now, and refine it as we move forward. It makes the entire workd of Slackware packages immediately usable. Note that dependencies are part of the standard .tgz Slackware package with the slack-required file. Once we build dependencies checking to handle that, it should be easy to refine it so that .ini files can do it too. More sophisticated .jar and .zip distributions will be handled with something more intelligent to be developed later. Joe, if what you have works in unRAID 5.0, then nothing stops you from using it.... so what is the issue if others use something else as a standard? Hell Latrtisnet continued making their non-standard 10BaseT hubs for years after the standard was adopted that did not include what Lattisnet proposed. When Tom first posted about having to use Ruby in unRAID 5, I didn't like it, but I was willing to go there since that was what made Tom's life easy. I was pleasantly surprised when 5.0 was actually php based. prostuff1: Making a tgz file is simple. In its simplest form, it is nothing but a tar archive with full paths run through gzip. You can include a script, description, and other information in specifically named files. I've sat on a lots of standards committees in my various jobs, and this discussion runs the risk of digressing into picking winners and losers (i.e. how someone is already doing something in the absence of a community standard) and picking the best way for forward development. I'm throwing out everything I've done before with bubbaRaid and unraidWeb -- I use it as a learning experience to inform future choices, but I'm leaving it behind for unRAID 5.0. unRAID 5.0 is new -- greenfield. Let's take a step back and look at things with a neutral hat.
July 20, 201015 yr Perhaps we go simple at the beginning... using ".disabled" on the .tgz files for now, and plan to add more sophisticated control via the .ini files as we get further down the field? This works for now. No, it does not work for now. It ONLY works if you do not use /boot/packages or have no existing packages I have these, and no way do I think re-naming them is "easier for now": ... Renaming them in a pinch is a small find or script. You can also move them to a "bak" or "disabled" directory. The find in the rc.local script does limit it's search to a -maxdepth 1 A disabled directory would work also. If these were in the /boot/extra directory you would have no choice but to move them out of there. There's nothing wrong with renaming them. where and how is open. If they do not conform to the supported package extensions that installpkg supports, skip them. Done. That slackware package is now disabled from being installed. This should be that way no matter what. I refuse the sit there and make a .ini file for every package when I can mv it. What I would expect is for a plugin manager to handle this all for me. So renaming them is not something you would have to do, the plugin manager would do it. And if there is a plugin manager, the files will be defined in the .ini file. Further along these lines, if there is an ini file, that can be renamed or a state variable can he set within. It seems straight forward to me. Perhaps I'm not understanding of the resistance. A further explanation would help. There are two levels of packages we are communicating about. I'm still on the most basic of slackware support packages. The /boot/extra or /boot/packages part of it.
July 20, 201015 yr I've sat on a lots of standards committees in my various jobs, and this discussion runs the risk of digressing into picking winners and losers (i.e. how someone is already doing something in the absence of a community standard) and picking the best way for forward development. I'm throwing out everything I've done before with bubbaRaid and unraidWeb -- I use it as a learning experience to inform future choices, but I'm leaving it behind for unRAID 5.0. unRAID 5.0 is new -- greenfield. Let's take a step back and look at things with a neutral hat. Well said, I see it as just flushing out a way of doing things.
July 20, 201015 yr prostuff1: Making a tgz file is simple. In its simplest form, it is nothing but a tar archive with full paths run through gzip. You can include a script, description, and other information in specifically named files. it was a bit of getting used to at first, but after you see a few slackbuild scripts, you can get an idea of what they are doing. If you grab the svn source of my powerdown package, you will see the slackbuild script there. It just builds a tree in /tmp/pkg, moves some files there. Then runs makepkg. I'm going to include it here just so you get an idea #!/bin/sh # based on the Slackware 12.0 SlackBuild # Packager Rob Cotrone ( WeeboTech at mydomain dot com) # http://lime-technology.com # Required: CWD=`pwd` TMP=${TMP:-/tmp/tgz} PKG=$TMP/powerdown NAME=powerdown VERSION=1.03 ARCH=${ARCH:-noarch} BUILD=unRAID SOURCE=http://www.cotrone.com/rob/projects/unraid/$NAME-$VERSION.tar.gz SOURCE=http://unraid-powercontrol.googlecode.com/files/$NAME-$VERSION.tgz if [ ! -e $NAME-$VERSION.tar.gz ] then echo wget -c $SOURCE fi if [ ! -d $TMP ] then mkdir -p $TMP fi if [ ! -d $PKG ] then mkdir -p $PKG else rm -rf ${PKG} mkdir ${PKG} fi cd $TMP # unused at this point # tar xvzf $CWD/$NAME-$VERSION.tar.gz echo -e "\E[0;32m+------------------------------------+\E[0;0m" echo -e "\E[0;32m| Start SlackBuild $NAME-$VERSION |\E[0;0m" echo -e "\E[0;32m+------------------------------------+\E[0;0m" if [ ! -d $NAME-$VERSION ] then mkdir -p $NAME-$VERSION fi cd $NAME-$VERSION find . -perm 777 -exec chmod 755 {} \; find . -perm 775 -exec chmod 755 {} \; find . -perm 555 -exec chmod 755 {} \; find . -perm 666 -exec chmod 644 {} \; find . -perm 664 -exec chmod 644 {} \; find . -perm 444 -exec chmod 644 {} \; chown -R root:root . # Here is where the manual build install commands go. install -d ${PKG}/sbin install -p -m550 ${CWD}/powerdown ${PKG}/sbin install -d ${PKG}/etc/rc.d install -d ${PKG}/boot/custom/etc/rc.d/unraid.d install -p -m550 ${CWD}/rc.unRAID ${PKG}/etc/rc.d # The rest should be standard on all installations mkdir -p $PKG/install mkdir -p $PKG/usr/doc/$NAME-$VERSION sed "s/#.##/${VERSION}/g" < ${CWD}/slack-desc > ${PKG}/install/slack-desc sed "s/#.##/${VERSION}/g" < ${CWD}/slack-desc > $PKG/usr/doc/$NAME-$VERSION/slack-desc cat $CWD/$NAME.SlackBuild > $PKG/usr/doc/$NAME-$VERSION/$NAME.SlackBuild cat $CWD/doinst.sh > $PKG/install/doinst.sh gzip -9 $PKG/usr/man/*/* cd $PKG requiredbuilder -y -v -s $CWD $PKG makepkg -l y -c n $CWD/$NAME-$VERSION-$ARCH-$BUILD.tgz if [ "$1" = "--cleanup" ] then rm -rf $TMP fi
July 20, 201015 yr I would not expect anything to automatically install every .tgz found. As I said, that is frequently not desired. (Although Tom in his latest release does have a "/boot/start" directory where every file in its installed with installpkg BEFORE emhttp is invoked.) This happens now with the "/boot/extra" directory. I don't see a problem with this other then it does not look for more specific files for installpkg. That's the directory I was referring to... (I did not remember the correct name though) It is fine for packages that are entirely self contained and need nothing other than to be "installed" If it's a known api that files in a directory are operated on in a specific manner, then when it's desired people will drop files there. My wish is that it's not in the rc.local script. Rather it is in a emhttp callout "boot" event so it can be controlled, modified, logged or disabled. I'm with you there. I think rc.local is the wrong place for it too. For my own use I did create an /etc/rc.d/unraid.d directory on my server which has package specific rc. scripts with "start" and "stop" script I invoke from post-array-start and pre-array-stop events I was generating using my own monitoring script. I've had that working for months now. I use it for cache_dirs and spinup_when_active scripts. I have no problem with the rc.package type of functionality ending up anywhere we collectively agree upon. Lots of processes will need to start after the database is available, and must be stopped before it is taken off-line. It is just the specifics we need to agree upon. I'd much rather emhttp call one "after-start" script, and one "pre-stop" script, one that we can then modify over time as we learn our actual needs, but Tom has previously described a "registration" process for events... I'm not sure if that is still the plan. We do know that there are many dependencies, so whatever plan is put into place, there needs to be a way to install package X before package Y. Joe L.
July 20, 201015 yr Perhaps we go simple at the beginning... using ".disabled" on the .tgz files for now, and plan to add more sophisticated control via the .ini files as we get further down the field? This works for now. No, it does not work for now. It ONLY works if you do not use /boot/packages or have no existing packages I have these, and no way do I think re-naming them is "easier for now": ... Renaming them in a pinch is a small find or script. You can also move them to a "bak" or "disabled" directory. The find in the rc.local script does limit it's search to a -maxdepth 1 A disabled directory would work also. If these were in the /boot/extra directory you would have no choice but to move them out of there. There's nothing wrong with renaming them. where and how is open. If they do not conform to the supported package extensions that installpkg supports, skip them. Done. That slackware package is now disabled from being installed. This should be that way no matter what. I refuse the sit there and make a .ini file for every package when I can mv it. What I would expect is for a plugin manager to handle this all for me. So renaming them is not something you would have to do, the plugin manager would do it. And if there is a plugin manager, the files will be defined in the .ini file. Further along these lines, if there is an ini file, that can be renamed or a state variable can he set within. It seems straight forward to me. Perhaps I'm not understanding of the resistance. A further explanation would help. There are two levels of packages we are communicating about. I'm still on the most basic of slackware support packages. The /boot/extra or /boot/packages part of it. 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. Several of the unMENU packages do that now. There is absolutely no need to install the compiler and compile support tools every time you reboot, especially if you only have 512Meg of RAM. They just take up too much memory. If /boot/extra installs everything dropped there, fine, that is what is expected. But /boot/packages is different. Only the packages with a control file are installed. Perhaps a combined approach will work. Currently, unMENU runs each of the package.auto_install files. If we added a bit of logic to the script processing the files in the directory, and added the "file" command so we could easily detect "slackware packages", we could add a .install suffix to ANY slackware package, and have the processing script first strip the suffix, and then if what remains is a valid slackware package, invoke installpkg on it. You get to rename package.tgz files with an added .install extension and have them installed, and I get to NOT rename all the existing downloaded package files in my /boot/packages directory. I can use the .install scripts we generate from the package.ini file contents. Joe L.
July 20, 201015 yr Why rename the files instead of using symlinks? Is it a limitation of possibly having them stored on a USB stick with FAT/FAT32 filesystem? I was thinking of initially having two directories, a main repository for packages, and a repository for which packages to install; using symlinks from /boot/packages/autoinstall to /boot/packages/repos. Even symlinks from /boot/packages/installed to /boot/packages/repos after the installation is complete. That would give an easy way to view what packages are currently installed.
July 20, 201015 yr At some point, could someone create for me an "executive summary" of ideas being discussed here, perhaps as a sticky? Reason is that the thread is growing faster than I have time to follow since I'm working on -beta2.
July 20, 201015 yr At some point, could someone create for me an "executive summary" of ideas being discussed here, perhaps as a sticky? Reason is that the thread is growing faster than I have time to follow since I'm working on -beta2. Keep coding beta2... In the mean-time, we'll collect the "requirements" and let you know what it has to do, as soon as we work it all out. Joe L.
July 20, 201015 yr Author Why rename the files instead of using symlinks? Is it a limitation of possibly having them stored on a USB stick with FAT/FAT32 filesystem? Renaming is faster and easier... php has a rename command that works much easier than making symlinks.
July 20, 201015 yr At some point, could someone create for me an "executive summary" of ideas being discussed here, perhaps as a sticky? Reason is that the thread is growing faster than I have time to follow since I'm working on -beta2. Sure, we are just discussing ideas right now.
July 20, 201015 yr Author Keep coding beta2... In the mean-time, we'll collect the "requirements" and let you know what it has to do, as soon as we work it all out. Wink Ditto.
July 20, 201015 yr Why rename the files instead of using symlinks? Is it a limitation of possibly having them stored on a USB stick with FAT/FAT32 filesystem? Renaming is faster and easier... php has a rename command that works much easier than making symlinks. Plus symlinks do not work on FAT/FAT32
July 20, 201015 yr Why rename the files instead of using symlinks? Is it a limitation of possibly having them stored on a USB stick with FAT/FAT32 filesystem? FAT/FAT32 file-systems do not do links or symlinks.
July 20, 201015 yr Before we continue. Is there a consensus on script callouts boot - emhttp first start start - after the array is online stop - before the array is stopped shutdown - after stop, before the system is shutdown The simpler form of script callouts for us to begin working outside of the whole "package management" topic. Was the configuration options I presented previously ok? http://lime-technology.com/forum/index.php?topic=7071.0
July 20, 201015 yr Before we continue. Is there a consensus on script callouts boot - emhttp first start start - after the array is online stop - before the array is stopped shutdown - after stop, before the system is shutdown The simpler form of script callouts for us to begin working outside of the whole "package management" topic. Was the configuration options I presented previously ok? http://lime-technology.com/forum/index.php?topic=7071.0 I can agree with these. The wait/nowait stuff (and anything extra we may want) probably needs to be discussed so we can flesh out this stuff before we continue with the other stuff.
July 20, 201015 yr Author 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. 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. /boot/<boot package dir> <-- slackware package files (for now) or other types of packages in the future. server/emhttp runs the install command (installpkg or somethign else specified in the .ini) rename to .disable to disable. NOT loaded if server is put into safe mode. anything not a Slackware package MUST have .ini file in order to run .ini files live in same dir. .ini file name same as appname from package file. Default install command is installpkg, but .ini can specify a different install command. rename to .disable WILL disable them (overriding .ini). NONE are loaded if server is put into safe mode. package manager always puts new packages here as DISABLED. .ini files - specify install command - specify the event commands (can be single command with parameters or individual scripts). a simple package manager will: - detect different versions of same package. - list packages in the UI - do enable/disable of packages - can run the appropriate install command on packages interactively.
July 20, 201015 yr Author I have a simple package manager done.... I'll make it into a package with some other utilities soon.
Archived
This topic is now archived and is closed to further replies.