AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |
Back to Blog
Debian package manager9/23/2023 ![]() ![]() For example, creating a - simple - package of a setuptool'ed Python program, is as simple as creating a couple of meta-data files and running debuild. See "FedoraProject: Staying close to upstream projects".Īlso, Debian has a vast amount of scripts that are able to automate a huge portion of creating a package. In the RPM world (at least among the Red Hat derivatives) this is frowned upon. In the Debian world, it is a bit more accepted to carry patches in a package that are not (yet) upstream. What I (think to) like about this approach is the fact that everything is contained in a single directory. (Forgive any mistakes here: I am a lot less experienced with deb's that I am with RPM's.) Debian packages' development files are contained in a directory per package. Debian packages also require the same tarball as upstream, though Debian policy requires some tarballs to be repackaged (thanks, Umang).ĭebian packages take a different approach. Generally, there are no exceptions to this rule. However, opinions differ.įor RPMs it is important to use the exact same tarball as the one the upstream project releases, up to the timestamp. IMHO, SOURCES gets cluttered pretty quick and you tend to lose track of what is in there. Now, personally, I like the fact that everything goes into the spec-file, and that the spec-file is a separate entity from the source tarball, but I'm not overly enthusiastic about having all sources in SOURCES. All source tarballs and all patches of all your packages are in SOURCES. Underneath, there is the SPEC directory for your spec-files, a SOURCES directory for source tarballs, RPMS and SRPMS directories to put newly created RPMs and SRPMs into, and some other things that are not relevant now.Įverything that has to do with how the RPM will be created is in the spec-file: what patches will be applied, possible pre- and post-scripts, meta-data, changelog, everything. In the RPM world, all your packages (the RPMs you maintain) are located in something like ~/rpmbuild. Main difference for a package maintainer (I think that would be 'developer' in Debian lingo) is the way package meta-data and accompanying scripts come together. It's just as good if not easier to use with the openSUSE build service at hand for a huge compatible package index. In my opinion, zypper has really closed the gap to apt and there is no reason to be ashamed of using an RPM-based distribution these days. ![]() Apt completely hid this problem for DEB packages because all packages got installed from the same source. RPM also suffered from sites like rpmfind where you would find 10+ incompatible packages for different distributions. The final installation of each single package is handed over to the low-level tools.įor a long time, apt-get has been superior in processing the enormous amount of metadata really fast while yum would take ages to do it. ![]() These tools download repositories, track all metadata and automate the downloading of dependencies. On top of these tools, there is repository management in the form of apt. Both dpkg -i and rpm -i have no way of figuring out how to install dependencies, except if they happen to be specified on the command line. They are both equally arcane, have hardcoded install paths (yuck!) and only differ in subtle details. The RPM and DEB formats are both just archive files, with some metadata attached to them. The real comparison is dpkg vs rpm and aptitude/ apt-* vs zypper/ yum.įrom a user's point of view, there isn't much of a difference in these tools. This however has nothing to do with the DEB file format. A lot of people compare installing software with apt-get to rpm -i, and therefore say DEB better. ![]()
0 Comments
Read More
Leave a Reply. |