I am working with RPM package manager for about a month now. Currently I want to use rpm -U to upgrade already existing content from previous RPM execution but I need to know the rpm package location on the file system.
The only way I can think of is searching whole file system for rpm name in %pre script but I would really like to avoid that option. Is there any way to get the path of the rpm package (package can be anywhere on the system) as a variable inside the spec file (%pre and %post script). Hope I explained my issue clearly enough.
Any help or proposal is welcome.
There isn't one location (or path) where a package is installed,
so I'm not sure what you are asking.
The files that are installed by a installed rpm package called "foo"
can be displayed with
rpm -ql foo
There is no common prefix on the paths except "/" in general.
Related
I have a rpm created for dev environment and CONTAINS a configuration file that points to dev. Now I have to create the rpm for another environment for which I need to replace just one file in the SOURCES folder and update the reference in .spec and rebuild it. Issue is that I don't have the .spec file that I used to create the rpm for dev.
So upon searching, came across rpmrebuild and I was able to see the .spec file in the editor.
When I give rpmrebuild command, the spec file opens in the editor.
Here's the small snippet from the file
/root/rpmbuild/SOURCES /root/rpmbuild/SOURCES
%files
%attr(0755, root, root) "/opt/**{replace/with/newfile/path**}"
But updating that that gives me - File not found: /root/.tmp/rpmrebuild.2345/work/root/opt/{path/to/newfile}
I don't know if I have to use rpmrebuild command with any --params in order to replace the file in the SOURCES and its reference in the .spec. There are no other changes to be made.
Please guide.
Note: I am a unix novice
I presume you do not have the src.rpm for this package. If you do, then it's very easy, simply install that with rpm -ihv /path/to/src/rpm as you would do with any RPM file. The contents, unless specified otherwise, will be extracted to ~/rpmbuild. The spec will be under ~/rpmbuild/SPECS, the sources under ~/rpmbuild/SOURCES, etc.
If you do not have the src.rpm but only the RPM itself, install the rpmrebuild package from the EPEL repos and then:
$ rpmrebuild -e -p /path/to/package
It will open the spec in your default editor. Edit it and save the spec wherever you want.
Then, assuming you have all the needed source files (declared in the spec using the SourceN directives), you can call:
$ rpmbuild -bb /path/to/spec
To rebuild the RPM from the edited spec.
I have an RPM I am making and this is in a very controlled environment so let's also assume it is safe to allow another RPM package to overwrite certain files contained from the original RPM package.
I know from experience if you try to install an RPM package that overwrites another RPM packages file's you get a warning that there is a conflict and the install fails (yes you can do some command line hacking but that is not ideal for the situation).
Is there any way through the original RPM packages spec file that you can specify these files are not part of the package they can be overwritten by another RPM package or is that just strictly prohibited from ever happening?
Is there any way through the original RPM packages spec file that you can specify these files are not part of the package they can be overwritten by another RPM package or is that just strictly prohibited from ever happening?
You can use %ghost directive for this purpose.
http://ftp.rpm.org/max-rpm/s1-rpm-inside-files-list-directives.html
I created a binary package with this command:
dpkg-deb --build -z9 -Zlzma $(DEB_SRC_DIR) $(DEB_DEST_DIR)
and install it on my Ubuntu 12.04 with this command:
sudo dpkg -i /path/to/package
The contents of the package I think are irrelevant.
Despite the sudo command the files in the installation directory belong to the current user and not to root as I expected.
How can I fix that?
Try to run the dpkg-deb command with fakeroot:
`fakeroot dpkg-deb ...`
(This will only help if the files in the source directory already have the correct ownership, which they probably dont. The problem you're actually trying to solve here, is to create an archive with files in it that belong to user root, which is where fakeroot theoretically helps.)
Let me say though, that what you are doing is not the best way for creating a binary package (far from it).
Instead, create a debian/ directory with dh_make (from the dh-make package), and edit the control file and changelog accordingly. You also need a file debian/install that lists what files you are installing and where they should go. There are various guides on the net (and on Stack Overflow) that explain this process. For example, look at the Debian New Maintainers' Guide.
You can then use dpkg-buildpackage to create a real, standard-conforming Debian package with your files in a reproducible way.
dpkg-deb is a low-level tool for manipulating existing deb files; it's not meant to be used for package creation.
Is it possible to keep RPM content in the filesystem after the uninstallation ?
Basically, I don't want to erase the files generated by the RPM when someone runs rpm -e, but still remove the package from the list of installed RPMs. I want to uninstall my application manually from the server and I cannot find a way to do so.
Thanks in advance.
Specfile creation
From this perspective as a package creator, you can flag files as configurations. John Warbrick at Cambridge Uni has a good rundown of the different file markings you can use in an RPM specfile and how they behave during upgrade.
Files marked %config, if changed, are:
left behind on uninstall but renamed with an .rpmsave extension
untouched on update or reinstall, but the payload copy is installed with an .rpmnew extension
Warbrick does not deal with straight package removal: if a file marked %config is unchanged, erasing the package will remove the file. (Bear in mind that, according to RPM scriptlet ordering, RPM update or reinstall begins with erasing the old package, before the new files are lain down. I.e., the old unchanged config is replaced with the new config.)
It would be an abuse of RPM file classification to mark something a %config that is not really a config. This is important because sysadmins need to be able to trust the package payload. Plus, you probably don't want such a file to be renamed with an extension.
Your best hope then is to create the file during RPM %post. Files copied to the filesystem in %install are checked against the %files list and stored in the RPM database, but files created in %post are not. Again, this an abuse of the RPM spec file format, but if you mention it in the %description and any other documentation, but especially if it's logically expected behavior in the context of your package, you'll maybe get some sympathy.
Existing packages
For sysadmins wanting to remove a package without removing its payload, you use rpm --justdb. First, check the file list:
# rpm -ql $PACKAGE | tee $PACKAGE.payload
[rpm returns list of files, tee saves it in the file $PACKAGE.payload]
# rpm -e --justdb $PACKAGE
(At this stage, you may get a complaint about deps, so repeat with --nodeps if you must.)
And finally, check that the package is gone, but payload is still there:
# rpm -q $PACKAGE
package $PACKAGE is not installed
# ls -l $(<$PACKAGE.payload)
[ls queries list of files saved in $PACKAGE.payload]
(Or for a more reliable ls if filenames contain spaces, which would be unconscionable in RPM.)
# cat $PACKAGE.payload|xargs -d '\n' ls -l
Other observations
Note that for a package created using the method outlined at the top of my answer, attempting to list the files it owns with rpm -ql $PACKAGE will not show those persistent files. Another consequence of throwing down files during %post is that another package which "owns" those files could overwrite them unexpectedly - they're not listed in the RPM database, so they're not protected.
The two methods I've outlined break Best Practices for both RPM package creation and sysadmin. Please be very careful how you use this dangerous "little bit of knowledge". Maybe there's something else you could do to create the desired situation.
(Finally, I know this is a question from four year back. It wasn't answered. It needed answering. Cheers.)
rpm -e --repackage package_name will drop a re-installable copy in /var/spool/repackage. You can extract from that rpm using rpm2cpio if you need those files back individually.
One of the advantages of RPMS is exactly that: you can uninstall (remove)
all the files easily.
If you want to install the files provided by an RPM manually,
simply unpack the RPM as root, with:
cd / &&
rpm2cpio *.rpm | cpio -idmv
It's not a good idea, but you can unpack RPMS like that elsewhere (e.g. under ${HOME}),
and that's very useful. You may need to adjust some environment variables though.
You don't pollute the RPM database but still use the contents of an RPM.
Of course your application may get broken by system updates,
because it is not protected by dependencies.
Anyway this is how you "install" and RPM if you are not root.
Removal is also easy (if installation path chosen suitably).
I have a debian package that I built that contains a tar ball of the files, a control file, and a postinst file. Its built using dpkg-deb and it installs properly using dpkg.
The modification I would like to make is to have the installation directory of the files be determined at runtime based on an environment variable that will be set when dpkg -i is run on the deb file. I echo out the environment variable in the postinst script and I can see that its set properly.
My questions:
1) Is it possible to dynamically determine the installation directory at runtime?
2) If its possible how would I go about this? I have read about the rules file and the mypackage.install files but I don't know if either of these would allow me to accomplish this.
I could hack it by copying the files to the target location in the posinst script but I would prefer to do it the right way if possible.
Thanks in advance!
So this is what I found out about this problem over the past couple of weeks.
With prepackaged binaries you can't build a debian package with a destination directory dynamicall determined at runtime. I believe that this might be possible if installing a package that is built from source where you can set the install directory using configure. But in this case since these are embedded Ubuntu machines they don't have make so I didn't pursue such an option. I did work out a non traditional method (hack) for installing that did work. Since debian packages simply contain a tar ball relative to / simply build your package relative to a directory under /tmp. In the postinst script you can then determine where to copy the files from the archive into a permanent location.
I expected that after rebooting and the automatic deletion of the subdirectory under /tmp that dpkg might not know that the file package existed. This wasn't a problem. When I ran 'dpkg -l myapp' it showed as still installed. Updating the package using dpkg/apt-get also worked without a hitch.
What I did find is that if you attempted to remove the package using 'dpkg -r myapp' that dpkg would try and remove /tmp which wasn't good. However /tmp isn't easily removed so it never succeeded. Plus in our situation we never remove packages but instead simply upgrade them.
I eventually had to abandon the universal package due to code differences in the sources resulting in having to recompile per platform but I would have left it this way and it did work.
I tried using --instdir to change the install directory of the package and it does relocate the files but dpkg fails since the dpkg file can't be found relative to the new instdir. Using --instdir is sort of like a chroot. I also tried --admindir and --root in various combinations to see if I could use the dpkg system relative to / but install relocate the files but they didn't work. I guess rpm has a relocate option that works but not Ubuntu.
You can also write a script that runs dpkg-deb with a different environment for 6 times, generating 6 different packages. When you make a modification, you simply have to run your script, and all 6 packages gets generated and you can install them on your machines avoiding postinst hacking!
Why not install to a standard location, and simply use a postinst script to create symbolic links to the desired location? This is much cleaner, and shouldn't break anything in dpk -I.