View Full Version : rpm vs deb method of tracking files
namphcar22
6th September 2010, 05:15 PM
When I create a rpm package with rpmbuild, I need to explicitly specify each file and directory I want to include in the package. Maximum RPM says that rpm has no way of tracking which files were installed by the package. When I create a deb package, dpkg-buildpackage assumes that the program was installed in the buildroot and simply wraps up everything in the buildroot. The effort shifts from manually recording the location of each installed file to making sure that all the files are installed in the buildroot (for example, using a make DESTDIR=$(buildroot) install). The latter approach seems much more convenient, especially when your package includes lots of files and directories. What is the advantage of requiring explicit file lists?
Skull One
6th September 2010, 05:28 PM
Your RPM source can provides many RPM packages (the package, the -devel, etc...), therefore you explicitly need to tell rpmbuild which file belong to which package.
If your RPM source provides only one RPM, it is easy to write a line for the tracking.
Dies
6th September 2010, 06:48 PM
...
What is the advantage of requiring explicit file lists?
explicit > implicit
It also allows for flexibility. For example, how would you build a deb out of files that are already present on your system?
I really don't think there is any contest between building an rpm and building a deb. Building an rpm requires a single file, which in most cases is easy to read. Building a deb requires an entire folder, with multiple files that typically need to be formatted in a specific way. And if you're not familiar with the system or all the dh_* commands, well good luck following along.
Of course it's all personal preference and experience but...
// off-topic... people still use dpkg-buildpackage directly?
namphcar22
9th September 2010, 04:48 PM
Thanks for your replies.
// off-topic... people still use dpkg-buildpackage directly?
I don't know. The debian manual still uses that command, although it does mention debuild as an alternative.
vBulletin® v3.8.7, Copyright ©2000-2013, vBulletin Solutions, Inc.