The easiest way to manage this is with access control lists. They allow permissions to be set for as many users and groups as you want, not just one user and one group like the basic unix permissions.
ACLs need to be enabled on the filesystem. With ext[234] or reiserfs, you need to pass the acl mount option. Also make sure you have the ACL utilities installed (acl package on Debian or Ubuntu).
Set an ACL that allows both users to access the files, and set a matching default ACL on directories (the default ACL is inherited by files created in the directory).
setfacl -m user:www-data:rwx -m user:svnuser:rwx -R /path/to/directory/tree
setfacl-d -m user:www-data:rwx -m user:svnuser:rwx -R /path/to/directory/tree
You can set different permissions if you like. The executable bit will be ignored if the file is not made executable through the non-ACL permissions (the ones you set with chmod).
The commands given are for Linux. Many other unix variants support ACLs, but the exact set of available permissions and the utility to set them are not standardized.
You can use groups to control access if you want. Even if you do, ACL have the advantage that you won't run into a umask issue: if you just create a group, you have to ensure that all files and directories are group-writable, which means you have to make sure any process creating a file has a umask of 002 or 007, which in turn may cause permissions elsewhere to be more liberal. So even if you create a group, ACLs are useful.
setfacl -m group:mygroup:rwx -R /path/to/directory/tree
setfacl -d -m group:mygroup:rwx -R /path/to/directory/tree
Note that I make no warranty as to the suitability of this security model to your use case. I'm just providing an implementation.
The problems you've had with alien are most likely not due to a bug or limitation in alien, but to an intrinsic problem of your approach. Converting a deb package into an rpm package is easy, and alien does it well. Converting a package for Ubuntu into a package for CentOS is much more difficult. This means not only repacking the files in a different format, but also moving files around to be in the directories where CentOS expects them, modifying configuration files so that they work on CentOS (e.g. with a different init system), declaring dependencies on packages that have different names (or might not even be present in the distribution at all), etc.
With 500 packages, you're probably going to encounter some difficult cases. Whether it's worth the effort to make dummy packages, create symbolic links and wrapper scripts, tweaking the system configuration, etc. is up to you, but I'd definitely be looking for another solution. In particular, note that there's a good chance that the Debian binariesare compiled against different library versions than what's present in CentOS.
If you want to run programs built for Debian on a CentOS machine, the least effort solution would be to install Debian in a chroot (this guide about installing Debian on another Debian version may be useful, as there's not much dependency on the host side).
If you want to have “proper” CentOS packages then building them from source will be far easier than converting the Debian packages.
Best Answer
Rpm and deb packages contain archives of the files to install (cpio archives in the case of rpm, tar in the case of deb). These archives contain metadata about each file, including its name, modification date, owning user and group, and permissions. When a package is installed, each file ends up having the ownership described in the archive (unless a post-installation script modifies it).
Most files installed by packages are owned by root, because no user is authorized to modify them.
Alien converts packages by unpacking the archive and repacking it (as well as other things like converting pre/post-installation scripts). For example, to convert an rpm into a deb, alien calls
cpioto extract the archive to a temporary location, thentarto build a new archive. If the unpacking is not done with root permissions, then all the temporary files will be owned by the user who is doing the unpacking, so when the files are packed into the new archive, they will end up being owned by that user.Alien doesn't actually need to run as root since it doesn't need to modify anything in the system. Fakeroot runs alien (or any other command) in an environment where that command receives fake information about filesystem operations, pretending that operations that normally require root (such as changing file ownership) have succeeded. This way, the unpacking is done as root and sets correct file owernship (as far as
alienand its subprocesses are concerned) and thus the repacking creates the intended archive.