I maintain a package that runs some services for datalogger communication. I am getting complaints that these services are not running after the package is installed in the latest version of opensuse. Currently, my postinst script for the package looks like the following:
/sbin/chkconfig --add csilgrnet
/sbin/service csilgrnet start
This, of course is executed by the package manager after the csilgrnet file has been added to /etc/init.d
Looking at the /etc/init.d directory, the only service scripts that I see there are the ones placed there by my package. I don't see the scripts there for any other packages or parts of the distribution. It would thus appear to me that the way that daemon startup scripts ways are managed has changed but I am clueless about the alternative.
Spring roo seems a convenient tool and I have a chance to try it. I created a linux package so that I can maintain it using the package manager to install or uninstall or share it in my team. The package manager will install the spring-roo to the /opt/spring-roo directory. But when running the roo command it will create a cache directory in the $ROO_HOME(/opt/spring-roo) and generates many small bundle files. But a normal user doesn't have the write access to the /opt/spring-roo. So my question is: is there a way to use another path as a cache directory just like the $HOME/.cache/roo? I noted that there is a config.properties in the $ROO_HOME but I can't figure a way to configure it.
After researching the roo.sh I found I can set the cache dir directly from the roo.sh. So I change it to the user's home, just likeROO_OSGI_FRAMEWORK_STORAGE="$HOME/.cache/spring-roo".
Alright so after trying to chase down the dependencies for various pieces of software for the n-th time and replicating work that various people do for all the different linux distributions I would like to know if there is a better way of bundling various pieces of software into one .rpm or .deb file for easier distribution.
My current set up for doing this is a frankenstein monster of various tools but mainly Vagrant and libguestfs (built from source running in Fedora because none of the distributions actually ship it with virt-diff). Here are the steps I currently follow:
Spin up a base OS using either a Vagrant box or by create one from live CDs.
Export the .vmdk and call it base-image.
Spin up an exact replica of the previous image and go to town: use the package manager,
or some other means, to download, compile, and install all the pieces that I need. Once again, export the .vmdk and call it non-base-image.
Make both base images available to the Fedora guest OS that has libguestfs.
Use virt-diff to diff the two images and dump that data to file called diff.
Run several ruby scripts to massage diff into another format that contains the information I need and none of the stuff I don't like things in /var.
Run another script to generate a command script for guestfish with a bunch of copy-out commands.
Run the guestfish script.
Run another script to regenerate the symlinks from diff because guestfish can't do it.
Turn the resulting folder structure into a .deb or .rpm file and ship it.
I would like to know if there is a better way to do this. You'd think there would be but I haven't figured it out.
I would definitely consider something along the lines of:
A)
yum list (select your packages/dependencies whatever)
use yumdownloader on the previous list (or use th pkgs you have already downloaded)
createrepo
ship on media with install script that adds the cd repo to repolist, etc.
or B)
first two steps as above, then pack the rpms into an archive build a package that contains all of the above and kicks off the actual install of the rpms (along the lines of rpm -Uvh /tmp/repo/*) as a late script (in the cleanup phase, maybe). Dunno if this can be done avoiding locks on the rpm database.
I think you reached the point of complexity - indeed a frankenstein monster - where you should stop fearing of making proper packages with dependencies. We did this in my previous work - we had a set of fabricated rpm packages - and it was very easy and straightforward, including:
pre/post install scripts
uninstall scripts
dependencies
We never had to do anything you just described. And for the customer, installing even a set of packages was very easy!
You can follow a reference manual of how to build RPM package for more info.
EDIT: If you need a single installation package, then create this master packge, that would contain all the other packages (with dependencies set properly) and installed them in the post-install script (and uninstalled them in the uninstall script).
There are mainly 3 steps to make a package with all dependencies (let it be A, B & C).
A. Gather required files.
There are many way to gather files of the main software and its dependencies. In order to get all the dependices and for error free run you need to use a base OS (i.e live system)
1. Using AppDirAssistant
This app is used by www.portablelinuxapps.org to create portable app directory. They scan and watch for the files accessed by the app to find required.
2. Using chroot & overlayfs
In this method you don't need to boot into live cd instead chroot into it.
a. mount the .iso # /cdrom and
b. mount the filesystem(filesystem.squashfs) # another place, say # /tmp/union/root
c. Bind mount /proc # /tmp/union/root/proc
d. Overlay on it
mount -t overlayfs overlayfs /tmp/union/root -o lowerdir=/tmp/union/root,upperdir=/tmp/union/rw
e. Chroot
chroot /tmp/union/root
Now you can install packages using apt-get or another method (only from the chrooted terminal). All the changed files are stored # /tmp/union/rw. Take files from there.
3. Using manually collected packages
Use package manager to collect dependencies. For example
apt-get install package --print-uris will print download uris for dep packages. Using this uris download packages and extract all (dpkg -x 1.deb ./extracted).
B. Clean garbage files
After gathering files remove unwanted files
C. Pack files
1. Using appImageAssistance
If you manually gathered files then you need to copy appname.desktop file from ./usr/share/applications to root of directory tree. Also copy file named AppRun from another app or extract it from AppDirAssistance.
2. Make a .deb or .rpm using gathered files.
Is the problem primarily that of ensuring that your customers have installed all the standard upstream distro packages necessary for your package to run?
If that's the case, then I believe the most straightforward solution would be to leverage the yum and apt infrastructure to have those tools track down and install the necessary prerequisite packages.
If you supply a native yum/apt repository with complete pre-req specs (the hard work you've apparently already completed). Then the standard system install tool takes care of the rest. See link below for more on creating a personal repository for yum/apt.
For off-line customers, you can supply media with your software, and a mirror - or mirror subset - of the upstream distro, and instructions for adding them to yum config/apt config.
Yum
Creating a Yum Repository in the Fedora Deployment Guide
Apt
How To Setup A Debian Repository on the Debian Wiki
So your customers aren't ever going to install any other software that might specify a different version of those dependencies that you are walking all over, right?
Why not just create your own distro if you're going to go that far?
Or you can just give them a bunch of packages and a single script that does rpm -i dep1 dep2 yourpackage
We have an application that runs as a service daemon on a RedHat system.
For now, the RPM we have to install this package creates a soft link from our application's library folder into /usr/lib64, and the daemon recognises that.
I would like to be able to set the LD_LIBRARY_PATH in the init script (/etc/init.d/myscript) so that we don't need to create that soft link (therefore, if multiple applications that use different versions of the library are installed, they will use what is in their own installation folder, and also we won't mess with the standard lib folders).
Is this possible? I tried a simple LD_LIBRARY_PATH=/opt/myapp/lib:/$LD_LIBRARY_PATH but that did not seem to work...
Try next in your init script:
LD_LIBRARY_PATH=/opt/myapp/lib:/$LD_LIBRARY_PATH
export LD_LIBRARY_PATH
I have created an Ubuntu package to install my RCP app. The installed files are owned by root. Is it possible for a user to subsequently install updates through P2? Documentation about Eclipse multi-user installs suggests that it is possible, along with the answer to this question.
However, when I start up the application, it does not automatically check for updates as usual, and the Update Site that I had specified in p2.inf is not listed in the "Install New Software..." dialog.
Using the -configuration or -data runtime options did not help.
I can make it work with a hack by running sudo chown -R <my_username> /opt/<my_app_installation>. When I subsequently launch the application, it does properly check for updates on startup, and my update site is properly listed in the "Install New Software..." dialog. Certainly I would prefer that whatever data it is writing to that installation directory be instead written to the user's home directory.
Supplementary info:
Here is a list of files and folders that showed up in my installation directory only after the directory was given ownership by <my_username> and the program was run.
/opt/<my_app_installation>/configuration/org.eclipse.core.runtime
/opt/<my_app_installation>/configuration/org.eclipse.equinox.app
/opt/<my_app_installation>/configuration/org.eclipse.osgi
/opt/<my_app_installation>/p2/org.eclipse.equinox.p2.engine/profileRegistry/profile.profile/1339896994308.profile.gz
/opt/<my_app_installation>/p2/org.eclipse.equinox.p2.engine/profileRegistry/profile.profile/.data/.settings/org.eclipse.equinox.p2.ui.sdk.prefs
/opt/<my_app_installation>/p2/org.eclipse.equinox.p2.engine/profileRegistry/profile.profile/.data/.settings/org.eclipse.equinox.p2.ui.sdk.scheduler.prefs
/opt/<my_app_installation>/p2/org.eclipse.equinox.p2.repository
More experimental results:
Even with a writable (chown'd) installation directory, no files are placed there when the
-configuration $HOME/.my_app_files runtime option is supplied.
There are lots of limitation of p2 itself for share install. AFAIK there is no significant improvement in latest release Juno as well.
But a guy from Redhat is working on p2 install with RPM package, you can read his progress in his blog post. The work and idea could be shared with Debian package.