I am trying to figure out which files were changed when I run an app install via make install. I can look at the script, but that calls other scripts and may or may not touch other files, etc. How can I do this programmatically?
Implementation: http://asic-linux.com.mx/~izto/checkinstall/
Several ways come to mind. First, use some sort of LD_PRELOAD to track all files opened. Second approach, compare filesystem before and after.
If your kernel supports it, you can use inotify (a handy interface is inotify tools) and watch your home directory, if the package was configured with --prefix=/home/myusername
I've noticed that checkinstall (using installwatch via LD_PRELOAD) does not always catch everything, the last time I used it it did not catch empty directories that were created for spooling, which caused the subsequent generated .deb's to break.
Note, don't use inotify if you are installing to /, in that case you have to use installwatch or just read all of the makefiles / install scripts closely.
Related
I have two fairly identical (Linux-) systems but one with just a minimum set of packages installed. On one system I have a running (binary/ELF) executable which I want to copy over to the other system (with the minimum setup).
Now I need a way to copy all needed shared libraries as well. Currently I start the application on the source system and then go through the output of
lsof | grep <PID>
or
ldd <FILE>
to get a list of all libraries currently loaded by the application and copy them over manually.
Now my question is: before I start to automate this approach and run into lots of little problems and end up with yet another reinvented wheel - Is there a tool which already automates this for me? The tool I'm dreaming of right now would work like this:
$ pack-bin-for-copy <MY_EXE>
which creates a .tgz with all needed shared libraries needed to run this executable.
or
$ cp-bin <MY_EXE> user#target:/target/path/
which would just copy the binary once..
Note: I do NOT need a way to professionally deploy an application (via RPM/apt/etc.). I'm looking for a 'just for now' solution.
One tool that does something similar to what you suggest is linuxdeploy. While the tool is intended to ease the creation of an AppImage (see here for more information), it will pack your executable with any dependencies into a directory. Then you can just create a 'tgz' file of that directory instead of an AppImage.
ldd usuage is correct if you also enable -Wl,--no-dynamic-lookup at link time.
After few weeks of struggle i am able to create a medium native package debian package which works well in installation and removing of the package.
As http://www.quietsche-entchen.de/cgi-bin/wiki.cgi/-wiki/CreatingDebianPackages
Debian wiki
http://wiki.debian.org/HowToPackageForDebian http://www.debian.org/doc/manuals/maint-guide/ these are the quite good material for beginners,
I have basic problem, in updating the package all the files data.tar.gz are updated by default.
I want only few files to get updated in the data.tar.gz based on a key variable stored in all the files.
After the unpacking that is executing preinst script, all the files in data.tar.gz are already updated..
my idea was to take back up of the files intially before upgrading the package, and check key variable in files.. if the key variable is greater than the current variable replace it..
which means i am writing a simple backup script.. and executing in the postinst file..
i donot think this is good idea.. and more over limitations in dash script make it a very tough job..
What are you trying to accomplish here? During the reinstallation (or upgrading) of a Debian package, replacement of all of the non-conffiles with the latest version is exactly what's supposed to happen. If the file hasn't changed since the last installed version of the package then there's no harm in updating it anyway, and if is has changed, it's supposed to be updated.
If you have specific files which might be modified by the user and should be preserved across upgrades, make then conf files. The package system will prompt the user and ask them if they want to keep the package maintainer's version or the locally modified version.
(But if you're going to make every file a conf file, then you're probably doing something wrong.)
To make a file a conffile, list it in debian/conffiles. But if the file is going to be installed under /etc then you don't need to do this because dh_installdeb will do it for you.
EDIT following additional information in comment:
Suppose you have files test1.sh and test2.sh (among others) in your package. In the Debian world, they are either conffiles are intended to be modified by the end user, or they're not.
conffiles should be relatively few in number and as short as possible, to minimize the burden of having to reconcile changes made by the package maintainer with conflicting changes made by the end user.
If there are things mixed into the code that the end user is likely to want to tune, try to factor them out into a configuration file. If you put that file in /etc, you don't even have to manually designate it as a conffile.
If the end user needs to make a change to a non-conffile, they should use the dpkg-divert protocol to (1) move the original file aside, and (2) edit a copy. Diverted files are respected by package upgrades. The end user who uses dpkg-divert should be aware that things might break after upgrades as a result, because the package maintainer hasn't foreseen that these files would be modified by end users and the locally modified version might be incompatible with a newly upgraded version of a different file. dpkg-divert should be used carefully and sparingly.
I've happily installed the vim Align plugin on my home computer, but on the Red Hat servers at work, the installation doesn't work. The servers at work have a very old copy (2006) of vimball, which from Googling I know doesn't support more recent vimballs, including Align. I can't get the systems group (IT department) to upgrade vimball, so I thought perhaps I could simply copy the various files into ~/.vim/plugin by hand. I copied the 3 files from my home system AlignMapsPlugin.vim AlignPlugin.vim cecutil.vim, but when I attempt to use Align from within vim I get the following error message
E117: Unknown function: Align#Align
I know that it's seeing the plugin, because when I remove the plugin the error message is different (it says "Not an editor command Align").
Is there a workaround for this? I love "Align" and would sure like to use it at work as well as at home.
{rtp}/plugin is not the only location where plugin files can be placed. The name of the function suggests that there is at least one file in {rtp}/autoload named Align.vim (autoloaded functions must have names looking like path#to#file#with#function#without#leading#autoload#function_name(), this example is for function located in {rtp}/autoload/path/to/file/with/function/without/leading/autoload.vim). But I strongly suggest that if #LucHermitte’s solution is not acceptable, you should use something that supports holding plugins in separate directories. If you used VAM all you needed to do (assuming that you have already installed align using VAM) is to look for files in ~/.vim/vim-addons/Align%294 and copy all of them.
Update: Forgot to say, you may try to install newer vimball plugin into your ~/.vim. In order to do this you need copy a file placed in /usr/share/vim/vim73/autoload/vimball.vim to ~/.vim/autoload (there is another related file, /usr/share/vim/vim73/plugin/vimballPlugin.vim, but it is not likely to be changed). No need to make IT department to upgrade anything, unless the newest version uses the newest vim features.
Install a recent (/the latest) vim in your $HOME. I've been doing this for ages now. It's the easiest way to get the job done (i.e. to have a proper environment).
I'm currently installing R software on a shared space across several servers. After installation I found that when I login on different servers, R is not guaranteed to run due to the missing of some library files on different machines.
Here is what I'm trying to do: since the installation of R is machine-dependent, I'd like to put all missing library files like libtermcap.so.2, libg2c.so.1, etc, to a single directory on the shared space, so that when I run ./configure, it will also search for this directory. Since this directory is shared, the installation could become machine-independent, so I won't need to add missing files on each server.
Is there an option to achieve this when I run ./configure? Thanks.
Assuming you have copied the library files to /shared/lib/ and the header files to /shared/include/, you can run
./configure LDFLAGS=-L/shared/lib CPPFLAGS=-I/shared/include ...other options...
Note, however, that you are bound to run into trouble at run time, when you have to convince your installation to use the shared libraries from the right directory, especially in case someone decides to upgrade the default version on the respective host. That whole business is platform and installation dependent. I think if your hosts are not at least mostly identical, you ought to install your software (R) locally in a way suitable to the respective system.
Peter's answer is correct (+1), and please take special note of his suggestion to install locally. Using the local package management system and auto updating on each box is (in the long run) a much easier solution than trying to get compatible binaries/libraries on a shared drive. To simplify using Peter's solution, note that you can place the appropriate arguments in /shared/share/config.site. For example:
$ cat > /shared/share/config.site << EOF
: ${LDFLAGS=-L/shared/lib}
: ${CPPFLAGS=-I/share/include}
EOF
Whenever you run configure with --prefix=/shared, the config.site file will be read and defaults will be set.
I've made a small script in my machine, and an alias in .bashrc that calls it. It's a bash script with 3 lines, but it can grow.
Now, some people in my team found it useful, and want to use it.
Instead of saying "copy this alias, do this, do that, install that lib" I was thinking about creating a simple package to be a little more professional. Fact is, I've never done something like this before. And the problem to me is not creating a package, is trying to decide what usually do you put in a package.
Suppose I want to take my script, and create myapplication. I want to create a .deb file that my team would install and:
Have a /usr/bin/myapplication or /usr/sbin/myapplication (what's the difference between them?), so they would just call myapplication at their terminal and it would work;
Have a man page; (Where are usually located man pages in a debian system?);
Have a possibility to read a .myapplicationrc in home folder with some configurations;
Have an entry for shortcuts in a gnome installation (is it possible to have an universal shortcut "format" that's is available to KDE and Gnome as well?);
Install dependencies.
I'm new to all that stuff. I usually code simple scripts and create an alias in my bashrc. I've never done a package before. Which guides do you know of that can help me accomplish what I thinking of above?
Here is a place to start, though I welcome a more succinct answer.
I couldn't find a complete guide. I think the best thing to do is download a package that does exactly what I'm thinking of and do some reading, like taskwarrior.