Recent Features
| |||||||||||||
packagingpackagingPosted Mar 19, 2013 2:24 UTC (Tue) by raven667 (subscriber, #5198)In reply to: packaging by geuder Parent article: Duffy: Improving the Fedora boot experience
> dpkg distinguishes configuration of the package. In the first installation this is probably similar to rpm %post%. But with dpkg you have to chance to reconfigure later, to my understanding with rpm you don't have that.
While RPM packages can have interactive scripts in pre/post handlers, it is not allowed by most packaging guidelines so you rarely see it. Allowing for interactive packages complicates centralized management, such as with RedHat Network/Spacewalk, because there is no one to show the UI to. So the tools are there to work that way but most distros have chosen not to do so.
> zypper has [...]
We should probably differentiate between features in the package format and features in the higher level manager because zypper is also working with RPM packages behind the scenes.
> zypper has the concept of vendor change, in yum I have at least never hit it.
That could be useful, yum does show which repo its pulling a package from when it presents the install/upgrade job to you for approval so if you are familiar with the system you can spot an upgrade coming from an unintended
> Debian supports multi-arch now. Does anything like this exist in rpm?
That's more of a distro question than a package manager one, RPM doesn't have any problem with bi-arch hosts and doesn't require special package builds to support it as long as the different arch packages don't have file conflicts. This is different than dpkg bi-arch which required separate 32bit packages with a different name to not conflict with the native arch packages.
I don't know if there are any distro plans to transition to multi-arch.
> Debian seems to have more additional tools than the others
As someone else pointed out these tools also exist in RPM land but I find that the functionality is spread out over fewer different tools and the UI is more consistent, for example yum does the job of both apt-get and apt-cache.
(Log in to post comments)
packaging Posted Mar 19, 2013 2:33 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
> While RPM packages can have interactive scripts in pre/post handlers, it is not allowed by most packaging guidelines so you rarely see it. Allowing for interactive packages complicates centralized management
with apt the installation process can be given a parameter indicating how much the user is willing to be bothered by interactive scripts (including, not at all for the enterprise situation you describe), and if they want a text-only display or prettier menu, etc.
> RPM doesn't have any problem with bi-arch hosts and doesn't require special package builds to support it as long as the different arch packages don't have file conflicts. This is different than dpkg bi-arch which required separate 32bit packages with a different name to not conflict with the native arch packages.
multi-arch allows for the package name to be the same for all the arches that are installed. It's significantly better than bi-arch (except when you run into one of the broken packages :-) and it can handle the idea that some packages are going to the same across all arches (mostly for scripting language based packages or artwork packages)
|
|||||||||||||