July 21, 201015 yr 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. I was trying to explain that those steps to me seem like what you said in a message later on. All the steps you described seems like they should be a SlackBuild, not in an install script. I'm thinking in this case it would be an unRAID companion package to the official slackware package. The end unRAID users would install the unRAID companion package. This companion package would be installed to /tmp/package. It could have its main code inside the doinst.sh or it could be separated out into a package.SlackBuild script that's invoked from doinst.sh. This unRAID companion package could do a wget on the official slackware package, or the official slackware package could be bundled inside the unRAID companion package. After the official slackware package is available, the companion package would do it's modifications. The last step it does is install the modified slackware package.
July 21, 201015 yr 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. I was trying to explain that those steps to me seem like what you said in a message later on. All the steps you described seems like they should be a SlackBuild, not in an install script. I'm thinking in this case it would be an unRAID companion package to the official slackware package. The end unRAID users would install the unRAID companion package. This companion package would be installed to /tmp/package. It could have its main code inside the doinst.sh or it could be separated out into a package.SlackBuild script that's invoked from doinst.sh. This unRAID companion package could do a wget on the official slackware package, or the official slackware package could be bundled inside the unRAID companion package. After the official slackware package is available, the companion package would do it's modifications. The last step it does is install the modified slackware package. OK, I understand now. See my other thread. http://lime-technology.com/forum/index.php?topic=7093.0
July 21, 201015 yr Author Downloading instead of embedding would require the end-user's unRAID server to have internet access in order to install the package.
July 21, 201015 yr When 5.0 came out, I needed to make a single small change to the php.ini file in the unraidWeb package. It took me 15 minutes since I had not been in there for a long time. Had it been a zip file, I could have done it in 30 seconds, by just clicking on the php.ini file, editing it, and saving it and winrar or winzip would have simply updated the package with the changed file. It also could have been done in 30 seconds if you use 7Zip on your WinOS.
July 21, 201015 yr Downloading instead of embedding would require the end-user's unRAID server to have internet access in order to install the package. Ahh the technician in us is micro managing. LOL. I'm not worried how that package is obtained. If we have our own repository, then it will exist. If we embed it it will exist. I'm more concerned with managing the tedium of long install procedures that go along with these advanced packages. If someone does or does not have internet access. I cannot worry about it. They will need some access to start. There is no way around it.
July 21, 201015 yr When 5.0 came out, I needed to make a single small change to the php.ini file in the unraidWeb package. It took me 15 minutes since I had not been in there for a long time. Had it been a zip file, I could have done it in 30 seconds, by just clicking on the php.ini file, editing it, and saving it and winrar or winzip would have simply updated the package with the changed file. It also could have been done in 30 seconds if you use 7Zip on your WinOS. As fast as it may have been, does it compensate or assist with versions? When an update is posted will it have a version or just the same name as always? When you do a slackbuld script and you know you are going to update and release a version, you will most likely edit the script, update the version and run it. There will be multiple files/versions and no mistake about.
July 21, 201015 yr Oh, I absolutely agree that all packages must be versioned. I think that's how installpkg/upgradepkg knows if a package should be upgraded or skipped and prevents reinstalls (unless forced). And I was pointing out that the arguments for using .zip instead of .tgz/.txz being one related to speed are moot given the proper tools.
July 21, 201015 yr Author If someone does or does not have internet access. I cannot worry about it. They will need some access to start. There is no way around it. A lot of unRAID servers don't have internet access... my production server does not..... The package manager I envision can download from the internet, or let you upload a package from your local Windows system via the web interface.
July 21, 201015 yr Author I posted a utility package in this thread: http://lime-technology.com/forum/index.php?topic=7094.0 It includes a super-simple package manager for /boot/extra.
July 21, 201015 yr Oh, I absolutely agree that all packages must be versioned. I think that's how installpkg/upgradepkg knows if a package should be upgraded or skipped and prevents reinstalls (unless forced). I'm not as sure it has that kind of embedded knowledge of versions... Slackware's installpkg is just a shell script that just uses tar on the uncompressed .tgz to overlay existing files, regardless of their relative versions. And I was pointing out that the arguments for using .zip instead of .tgz/.txz being one related to speed are moot given the proper tools. true... does it really matter if it takes 5 seconds, or .5 seconds. Users will expect longer installation times for larger packages. (downloaded Window's SP1/SP2/SP3 lately... time is not measured in seconds... but potentially hours on a slow connection) as far as internet connectivity, it is for that reason I display the download URL in the unMENU package manager. A user can click on the download link, download to their PC, move it to the unRAID server /boot/packages directory, and then the package manager will find it, verify the MD5, and use it without attempting to download it. Of course, unMENU uses network connectivity to update its release list, so to use the current version of unMENU network connectivity is needed. If the new package-manager on unRAID is going to do anything similar, to present to the user a list of currently available packages, or to alert a user when an update is available, then it will be necessary to have network connectivity. It will be running on unRAID 5.0, and if not able to get a list of packages to display, have nothing to show the user. I think that bubbaQ is probably in the minority in that his production unRAID server is isolated from the web. (First, because most people only have a production server, and second, if they do, because their routers are not isolating it from the web, and third because to use the nntp servers, it must have connectivity ... unless you are running an nntp service on a different PC on your LAN and syncing to that.) Personally, I have two unRAID servers, both have web access so I can use "wget" etc.
July 21, 201015 yr Author I see two distinct different parts of the package manager. One is dealing with packages found in the /boot/packages directory. A completely separate, but related, function, is getting the packages into /boot/packages. That can be done via Internet connectivity, but also manually, and via an upload from a local system. I may surely be in the minority by having a prod server blocked from direct Internet acces, but my work (and several protective orders) requires it. I don't want a system that is unusable by a server w/o Internet access. That is why the functionality of processing the package files found in /boot/packages should be independent of Internet access.
July 21, 201015 yr Oh, I absolutely agree that all packages must be versioned. I think that's how installpkg/upgradepkg knows if a package should be upgraded or skipped and prevents reinstalls (unless forced). I'm not as sure it has that kind of embedded knowledge of versions... Slackware's installpkg is just a shell script that just uses tar on the uncompressed .tgz to overlay existing files, regardless of their relative versions. It's upgradepkg that has the smarts. I use the two interchangeably, though as you said installpkg will blindly go ahead and reinstall even if its already installed. upgradepkg zlib-1.2.3-i486-2.txz +============================================================================== | Skipping package zlib-1.2.3-i486-2 (already installed) +============================================================================== installpkg zlib-1.2.3-i486-2.txz Verifying package zlib-1.2.3-i486-2.txz. Installing package zlib-1.2.3-i486-2.txz [REC]: PACKAGE DESCRIPTION: # zlib (compression library) # # zlib is a general purpose thread safe data compression library. The # data format used by the zlib library is described by RFCs 1950 to # 1952 in the files ftp://ds.internic.net/rfc/rfc1950.txt (zlib format) # rfc1951.txt (deflate format) and rfc1952.txt (gzip format). # Executing install script for zlib-1.2.3-i486-2.txz. Package zlib-1.2.3-i486-2.txz installed.
July 21, 201015 yr That is why the functionality of processing the package files found in /boot/packages should be independent of Internet access. I'm not going to argue this point. This was one of my thoughts for the "downloads or updates" folder. These are not processed/installed automatically. So an advanced build/prepare package could be downladed here. Installed (processed) then subsequently putting the final prepared package in the proper /boot/packages directory.
Archived
This topic is now archived and is closed to further replies.