Frequency of booting [LWN.net]

packaging

Posted Mar 18, 2013 22:42 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

> I haven't worked that much using yum, but I have failed to find the concept of recommended in yum. Does it exist?
> zypper has recommended and apt even has recommended and suggested.

I think rpm5.org's RPM has Recommends/Suggests (which OpenSUSE uses), but Red Hat's RPM (4.x) does not. I don't know the status of it.

> zypper has the concept of vendor change, in yum I have at least never hit it.

"Vendor change"? Which repo provides which package or vendor in .desktop files?

> 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.

What do you mean by "reconfigure"? Reset to RPM-shipped defaults? The UIs that appear when installing server packages on Debian? IME, in RPM-land, other than defaults, it's usually up to $EDITOR.

> Debian supports multi-arch now. Does anything like this exist in rpm?

Fedora does biarch, but I'd fully support Debian-style multi-arch coming to Fedora. It's a much cleaner setup overall.

> Debian seems to have more additional tools than the others. apt-file, debfoster, and debtree come to my mind, I've used all of them occasionally (I'll be glad to hear what are the equivalent tools on the other side of the fence)

There is rpmdevtools which contains things like rpmdev-extract, rpmdev-diff, etc. As for the apt-* commands, I always forget which is used where. Most of those have analogues as subcommands of yum or flags to "rpm -q" (`rpm -qf /path/to/file` gives package(s) which installs the path).

> On the other side the automatic mirror selection in yum and believe also in zypper is superior what I'm used to in Ubuntu. There I end up manually editing the apt source list each time my country mirror suffers from some hickup.

Broken mirrors (404, hash mismatches, etc.) are handled gracefully by yum, but getting yum to stop using a slow mirror isn't the easiest. Ctrl-C is supposed to make yum stop its current download and restart it (preferably with a different mirror), but sometimes it gets all the way through and yum quits instead. Unfortunately, Ctrl-C to cancel things doesn't always work either (this is one of my gripes with Python in general).

packaging

Posted Mar 18, 2013 23:27 UTC (Mon) by geuder (subscriber, #62854) [Link]

> "Vendor change"? Which repo provides which package or vendor in .desktop files?

If the attribute displayed by

rpm -q --qf "%{VENDOR}\n" <package>

changes during upgrading an package changes zypper will warn you. It typically happens if you pull in dependencies built by yourself or from some independent repo. Not really sure how important that is, but it might be nice to know just in case something breaks.

> What do you mean by "reconfigure"?

It's not me, it's Debian that means...

http://manpages.ubuntu.com/manpages/precise/man8/dpkg-rec...

I have used to to change the keyboard layout of installed systems (it can be a major annoyance if they sell you only computers with non-US keyboards in your country and all software assumes US layout). I'm sure there are other uses, but probably not everybody's everyday stuff.

> The UIs that appear when installing server packages on Debian?

I guess we could mean the same. If the dialogs cause trouble check

http://manpages.ubuntu.com/manpages/precise/man7/debconf....

> There is rpmdevtools which contains things like rpmdev-extract, rpmdev-diff,

Without knowing exactly what they do after a quick glance to the man page, I don't think they are comparable to the ones I mentioned

- debfoster: helps to remove unnecessarily packages (stuff that nobody depends on anymore)
- apt-file: search for which not yet installed package contains a certain file.
- debtree: produce graphical dependency trees of installation or build time dependencies.

> Most of those have analogues as subcommands

I fully agree as far as basic set of rpm/zypper/yum vs. dpkg/apt commands is concerned. The more advanced, optional things as the 3 examples above I have never seen in the rpm world (I don't absolutetly claim they don't exist)

> but getting yum to stop using a slow mirror isn't the easiest

It gives up if less than 1 Byte/sec (I believe) is transferred for some time (which might be a bit too long) That is OK-ish if I do installations on the train and the network freezes. It might not be godd enough if you are on a fixed network and server is just really overloaded. Yes, I remember some buggy behaviour when using Ctrl-C.

packaging

Posted Mar 19, 2013 0:02 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]

There are tools you might not be aware of

localectl (standard part of systemd)
package-cleanup --orphans
repoquery
rpmorphan package has rpmdep

packaging

Posted Mar 19, 2013 12:39 UTC (Tue) by geuder (subscriber, #62854) [Link]

Thanks, these are useful pointers.

Currently I use on RHEL/CentOS, maybe Fedora some day again in connection with some distro hopping...

> localectl (standard part of systemd)

If it's systemd I guess it's Fedora only

> package-cleanup
> repoquery

Contained in package yum-utils

> rpmorphan

Doesn't seem to be in RHEL or EPEL.

packaging

Posted Mar 19, 2013 14:32 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]

This discussion was about Fedora originally but you can easily take the srpm from Fedora and build it for RHEL if you would like to, esp for rpmorphan.

http://koji.fedoraproject.org/koji/packageinfo?packageID=...

There are other alternatives for RHEL that might be available in EPEL. I haven't checked since I am not running EL.

packaging

Posted Mar 19, 2013 22:42 UTC (Tue) by HelloWorld (guest, #56129) [Link]

> > localectl (standard part of systemd)

> If it's systemd I guess it's Fedora only
Why do you think that? Quite a few distros have switched to systemd already, including openSUSE, Arch Linux, Mageia and others.

packaging

Posted Mar 20, 2013 10:03 UTC (Wed) by micka (subscriber, #38720) [Link]

I guess it's fedora only v.s. fedora+rhel/centos.

packaging

Posted Mar 21, 2013 17:58 UTC (Thu) by nix (subscriber, #2304) [Link]

rhel hasn't switched yet, though it will. :)

packaging

Posted Mar 19, 2013 13:52 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

I think that Fedora doesn't use Vendor in its RPMs. I usually just get watchcommit permissions on packages I have persistent patches no one will accept. Sure, it only works for Fedora packages (not RPMFusion, etc.), but that's been sufficient for me. A plugin to yum which warns when the repo changes shouldn't be too hard.

packaging

Posted Mar 19, 2013 2:24 UTC (Tue) by raven667 (subscriber, #5198) [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, 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
place but that's clearly not as good as explicitly pointing it out.

> 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.

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)