I have an application in /opt/MyApp that I need to pack into an RPM package using FPM as follows:
fpm -e -s dir -t rpm --name 'MyApp' --version '1.0' --iteration "12345" --directories /opt/MyApp --epoch 0 /opt/MyApp
(other options are not relevant here)
All files and directories in MyApp are owned by root (both user and group). Also there is a directory called "help" with different permissions like
drwxrwxrwx.
i.e. all users can write into that directory.
When I inspect the spec file generated by FPM, it has
%defattr(-,root,root,-)
and all directories (%dir) and files are then listed, so I would expect that all original permissions are preserved in this package. However, when I inspect it using
rpm -qlvp MyApp.rpm
the permission on the "help" directory are reset to:
drwxrwxr-x
i.e. other users cannot write there anymore.
My first guess was to add the option
--rpm-use-file-permissions
but it made things even worse, because now all files in RPM are owned by the user that called FPM.
Edited:
I've achieved the result using
--rpm-use-file-permissions --rpm-user root --rpm-group root
but still it doesn't feel elegant and flexible.
Thanks in advance.
The comment about %defattr, and absence of comments about the BUILDROOT tree may indicate some confusion. According to rpm.org:
If a particular attribute does not need to be specified (usually because the file is installed with that attribute set properly), then that attribute may be replaced with a dash
That is, if no explicit permission is given in %defattr, then the permissions from build-time %install when constructing the rpm are satisfactory. There is no guarantee that those match (or are even compatible with) the actual system on which the rpm is later installed.
Related
I have created quite a few deb files, i have no problems doing that and they all run beautifully. However, if i want to replace a file in users home directory I am unsure on how to do that.
I have tried making a postinst to rsync the files from a predefined location to home directory, but since the postinst file is being run as root ( due to the debian installer running as root ) it is being sent to the root home directory and not the user's home directory....
Here's an example of the deb file contents :
Debian Directory ---> Control File ----> Postint File
usr/share/desktop (directory with files inside)
The postinst file has the sync command to send those files to users home:
#!/bin/sh
rsync -av /usr/share/desktop/ ~/.config/desktop/
The problem is it is sending the files to Root/home... not the default users home :(
I don't have the username of the user since this will be used on many computers with different users, therefore I can't use sudo -u username.
So what do I do? how do i replace files in users home directory from deb install? Any help is much appreciated.
In a Bash script, ~ refers to the current user's home directory. The package installation scripts are always run as root, so that's what "current user" means in this context.
(You could argue that the package installation is probably initiated by a user running su or sudo, but in the general case, you cannot assume this to be the case.)
Modifying user files from a system package appears extremely suspicious in any event. If the need is genuine, this should probably not be approached as a system package installation question in the first place. What are you actually trying to accomplish?
Not only are you violating the basic principle that package management should not meddle with user files; a consequence of this arrangement is that the operation can only be performed once: If the user has installed the package, attempting to install it again does nothing (at least until you uninstall).
A more manageable and predictable approach would seem to be making the package provide this functionality, but leave it to the user to invoke the actual sync (overwriting) script as needed. Perhaps you want to hook it into the desktop startup scripts somehow.
Having said that, sudo exposes the invoking user's identity in $SUDO_USER so you could look for that, and simply fail if it is not set.
As an aside, package scripts should work with dash so you need to avoid bashisms - prefer $HOME over ~, for example.
I managed to find a workaround, although it is not exactly what I was looking for, but here is my solution, at least for now.
#!/bin/sh
#This will move the desktop settings to required folder.
szAnswer=$(zenity --entry --text "Enter your login username\nThis must be entered correctly\n" --entry-text "Enter name of profile to use:")
xfce4-terminal -e "sudo rsync -av /usr/share/Desktop/ /home/$szAnswer/.config/xfce4/"
exit 0
In other words, the user gets asked to enter his username, and the files get copied to that user's home directory. The advantage is that if he does have multiple users, it will use the correct user. The disadvantage is if he enters username wrong, even a spelling mistake, the install will fail.
But it does work, I have tested. If anyone has a better solution I eagerly await your suggestions.
Consider a SPEC file containing:
%install
install -m u=rwx,g=rx,o= -D bin/blah.jar ${RPM_BUILD_ROOT}%{_libexecdir}/foo/blah.jar
Then in the %files section, the permissions are not changed (say, %defattr(-,bubba,users,-)).
Installing the RPM results in blah.jar having permissions 644 instead of 640. Indeed, no matter what permissions are used in the install command, they're reset to the default 640. I've found that the cause is the jar repacking, as permissions are maintained if I disable repacking by adding %define __jar_repack %{nil} to the SPEC file.
This is a nasty bug of the repacker.
How do I get both repacking to work and the permissions to be preserved (and I mean preserved, not setting them instead in the %files section, as then I'd have to mention individual files not only in %install but in %files as well, rather than just whole directories in the latter)?
Created a simple debian/ubuntu package with some library files (*.so).
Works fine except, it installs them as default in the root path "/".
Since I've recreated my Makefile to output to $DESTDIR/ instead of "the usual" directory that I provide in the Makefile, when compiling from source, how do I now set the path of where the files should be installed now? I know there are several choices when using dh_make to create the package, "s" being the default one. Still, can't seem to find anything on where to tell dpkg to put the installed files.
Secondly, a Deb Library package containing only ".so" files should still be a "Single binary" since I gather that using the Library is for development purposes? Since this is a library, I just wanna make sure that's not the cause of the files being installed in the wrong location. What I mean is .so files and header files installation?
What I've used:
dh_make -e my#email.com -f ../myfile-1.0.tar.gz
dpkg-buildpackage -rfakeroot
and some configurations set i debian/control, $DESTDIR in Makefile.
Seems that it was fairly simple, yet very confusing. This works, not sure if there is a better solution.
In my makefile I have a few variables
InstallTo = /usr/lib
install:
mkdir -p $(DESTDIR)$(InstallTo)
cp $FILE_TO_COPY $(DESTDIR)$(InstallTo)
This way it will create the directory tree inside the *.deb file. I had some trouble using /usr/local/lib instead of /usr/lib/ and rmdir complained when trying to delete it and it had no files (just directories). Not sure why, but changed it to /usr/lib instead.
Since someone voted this up, I'm guessing someone were also looking for the answer and this is my solution. Perhaps someone can provide a better one if there is one.
Just a note, $DESTDIR variable is the variable that dh_make suggest the user to use in our Makefile. It's the path to where dpkg will build the program and where it will install it so it can be included in the .deb file.
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.
In the process of building an RPM package, I have to specify the BuildRoot and later will be used in %install which invovles $RPM_BUILD_ROOT. I always think that $RPM_BUILD_ROOT is the fake installation for RPM to perform packaging. Then, at install time using the RPM package, it will install into actual location. For example:
$RPM_BUILD_ROOT/usr/bin
I thought that $RPM_BUILD_ROOT is for the packaging process only, and in some ways RPM can distinguish the $RPM_BUILD_ROOT and the actual install location when the user performs "rpm -ivh package.rpm" will be /usr/bin.
But recently upon reading some documents, it is suggested that $RPM_BUILD_ROOT is the actual location which will be installed, and the $RPM_BUILD_ROOT is specified by user with the setting of environment variable $RPM_BUILD_ROOT in order to let the users install the package in their desire locations. Otherwise, $RPM_BUILD_ROOT will be null and it will install into the default location. In the above case, it is /usr/bin . Thus, $RPM_BUILD_ROOT is not just for packaging or "fake installation" process, but is a way for user to define install location, similar to select folder location in Windows.
I don't know my thinking is correct or not. Can someone please verify? Thanks in advance.
$RPM_BUILD_ROOT (or the equivalent %{buildroot} SPEC file macro) always holds the directory under which RPM will look for any files to package. The RPM scripts (e.g. the script that compresses the manual pages) will also use that value to know where to look for the files that were just installed. Normally, this value will be non-empty and contain a location away from the system directories - usually somewhere under /tmp or /var/tmp.
The author of the SPEC file is expected to make sure that make install (or whatever installer the software in question is using) will place any files under $RPM_BUILD_ROOT, with the same hierarchy that should be used when the software is finally installed. E.g. to have RPM install ls in /bin/ls, the %install SPEC file section should make sure that ls is placed in $RPM_BUILD_ROOT/bin/ls.
The author of the SPEC file is also expected to use the BuildRoot: tag to specify a proper location. Alternatively, the build system could have an rpmrc RPM configuration file with a proper entry. In any case the build root should be set, so that:
Normal users will be able to build the source package.
Should the superuser ever build the source package, the build process will not clobber any system files, unless the superuser installs the resulting binary package. And yes, there may be a good reason to build some packages as root - for example, running the full glibc testsuite requires root privileges for some tests.
That said, RPM can and will build a package with an empty build root variable. In that case both the build install and the final destination locations will coincide. A potential call to e.g. make install will use the default locations, thus clobbering the system files under e.g. /usr/lib if run with sufficient privileges. Additionally, having /usr/bin/* in your %files section will happily pull the whole contents of the build host /usr/bin/ directory into your binary package.
Bottom line:
Never use an empty build root.
Do not build packages as root unless there is absolutely no other way.
the file ~/.rpmmacros defines the paths per user:
%_topdir %(echo $HOME)/rpmbuild
%_tmppath %{_topdir}/tmp
and one can also define them with rpmbuild command line parameters:
rpmbuild --define '_topdir /home/username/rpmbuild'