Sometimes the installation command needs write access to the current directory. This is often due to libtool wanting to relink some libraries at installation time. Sometimes also the installation program wants to use some log file or touch some temporary file.

Most of the time, the package user does not have write access to the build directory. What you usually do is to extract the tarball as a normal user, cd to it and begin to build. In that case, the default permission of the current, build directory should be something like 0755. Therefore the package user does not have write access.

You should definitely arrange for the current directory to be world writable. A quick and dirty way to do that is

      $ chmod o+w .
    

If that is not enough (sometimes the installation script needs write access to other existing files for example), you could just go with

      $ chmod -R o+w .
    

The installation program wants to write somewhere it is not allowed to.

If you want to allow the program to write there, just use --gen to make the location an install directory.

If you don't want the program to write there, then you have a bit more work to do. Maybe you made a mistake specifying the destination paths at configure time (e.g you gave the /usr/local prefix instead of /usr). Sometimes the program just wants to install some locales and in that case you just have to create the destination directories, make them installation directories and run the install command again. As a last resort, you can consider going into the Makefile (or whatever installation script you are using) and changing the lines that cause problems. You can then complain to the program's maintainer about this unexpected behavior.

The installation program wants to change the permission of some directories like /usr or /usr/bin, e.g to 0755 while they are install directories. It can also happen that it wants to change their owner and group to root.

The installation program could also want to change the ownership of some of its executable to root, or some other user.

The permission / ownership change of install directories is due to poorly written installation script. The command that causes this is usually something like

      $ install -d /usr/bin
    

If the directory already exists, its permissions will be changed to 0755 which is typically not wanted in our case. A command like

      $ install -d --owner=root --group=root /usr/bin
    

is even worse since it does not take into account the possibility of installation in a user's home directory for example. In both cases, the solution is simple: remove those commands from the offending Makefile / installation script and complain to the maintainer.

If the installation program tries to change the ownership of its own executable, this is also unwanted except if the executable are suid or sgid. In any case, you cannot allow this change to happen so just remove the offending lines from the Makefile and change the ownership and / or permissions of the files afterward if you really want to.

Regarding suid and sgid programs, you should never use the package user as a user or group for a suid or sgid file. The reason for this is that package user still have more privileges than ordinary user, and should not be used for anything else but installing packages.

Some installation program sometimes try to overwrite files from another package, or even delete them so that they can be replaced with the new versions the installation program provides. Since urpkg does not allow them to overwrite files, the installation command fails.

The solution depends on what the installation command intends to do with the files. If they are e.g index files, like /usr/share/info then you can consider making them shared files using --share. If you don't want your old files to be erased, just copy them somewhere and copy them back after the installation. If you want your old files to be erased, just remove them or move them somewhere else.

In the end, make sure to check what packages the files you moved around belong to. Don't hesitate to use the --free-files and --add-files options to move files to a different package.

Some install script run ldconfig. Since they don't have permission to write to /etc/ld.so.cache, this command fails

Most script won't fail just because ldconfig fails. In any case, ldconfig will be run automatically afterward by a postinstall script.