Use apt+dpkg

Latest response

Yum is just terrible, its still years behind apt (and friends). Debian, Ubuntu and friends have largely made apt largely ubiquitous.

 

Please use apt for package management... and swap from rpm to dpkg with it. (ok you could use apt-rpm)

 

This also greatly reduces the learning curve between RHEL and more common 'learner' linux distributions.

 

Responses

The move from, yum to apt, should be like the move from, up2date to yum.  That is, not disruptive to the underlying system.  A move from rpm to deb/dpkg would be quite disruptive to the underlying system.

 

Agreed that apt is a much better front-end than yum.  Meta-packages on Debian/Ubuntu such as "build-essential" make more sense than yumgroups such as "@Development tools".

What's so bad about yum in its current implementation that it should be replaced with apt?  What is so much better about apt?

 

How about all of the time invested in spec files and the rpms that have been built in-house by sysadmins against yum/rpm-based tools for the last decade?  We'll have to go through a learning curve to move to a new build system.

 

Why do meta-packages make more sense than yum groups?

 

You'd probably have to convince the Fedora project to do this as well.  They have an entire ecosystem built on rpm/yum that would have to be ported or replaced.

 

Seems like a very tall order.

Apt can be dropped in as a replacement front-end for yum without effecting the backend rpm/spec dependencies.  Which is exactly what I suggested, keep the backend rpm and spec files, drop-in apt as an available sidegrade.  Is there any reason, both apt and yum could not be available as package management front-ends to RPM?

 

Meta-packages make more sense from a configuration management and systems automation perspective.  Its much easier to create a dependency for something like "build-essential" the meta-package in Debian/Ubuntu.  As opposed to figuring out how to properly escape and reference "Development tools" or @"Development tools" in a dynamic scripting language.  Both the space characters in yumgroups and the special @ symbol used to signify this is a package group create an annoyance in terms how the yumgroup naming conventions are referenced in scripting languages.

 

Within kickstart, the naming conventions of yumgroups are certainly not a problem.  Within other scripted languages, I have had to tediously enumerate the output of "yum groupinfo" against a given yumgroup to create a manual list of dependencies.

Note that the installer, the update tool with RHN, and assorted other utilities are bound to the yum API, not apt. Ergo, it's not a simple/practical switch.

Thats a really good point.

 

I guess the practicality of switching front-end package management depends on a couple things:

 

  1) if the metadata for both can live within the repo on the server end of package management.

  2) if both systems can seamlessly co-exist and operate on the client end of package management.

Escaping spaces and @s in the group names is a problem worthy of tossing out yum altogether?  A better request would be to stop using spaces and @s in the group names rather than switching to apt.  But really, where is this even a problem?  Also, I'm not sure what "dynamic scripting language" you are using that can't handle properly escaping spaces and @s, but that hardly seems like a problem with yum.

I absolutely never said toss out yum, altogether.  What I said, in so many words, I don't see why apt and yum cannot co-exist as package management front-ends.

 

The meta-package vs yumgroup naming conventions is certainly a problem with package installation when trying to automate within Ruby, Puppet DSL, Chef DSL.  By the time RHEL7 is released it will probably have been worked around within that space.  Perl also uses @ as a special character for arrays so it may be a problem for folks using CFengine. 

 

Let me illustrate the yumgroup problem with an example in configuration management pseudo-code. Within Debian/Ubuntu the pseudo-code amounts to the following for the set of packages providing make, gcc, etc.

 

# Simple double-quoted string passed directly to 'apt-get install'

package "build-essential"

 

Within Redhat, none of the following pseudo-code would work without a sub-provider for the package resource that contextually detects whether it should call 'yum install' or 'yumgroup install'.  The package management utilities, yum and yumgroup, are functionally separate and syntactically incompatible.  With meta-packages there is no need for a functionally separate package management utility for groups of packages.

 

# To install a yumgroup with a pure yum resource provider,

# you have to literally pass @"Development tools" to 'yum install'.

package "\@\"Development tools\""

package '@"Development tools"'

package 'Development tools'

package '@"Development tools'

package "Development tools"

 

The following pseudo-code however, will work.  I'm required to compile a list of manual dependencies to satisfy the same need.  With each revision of RHEL, I may need to manually compile a separate set of manual dependencies.  The yumgroup has failed to accomplish the purpose of grouping packages, in this particular case of abstraction within configuration management.

 

%w{ autoconf automake binutils bison flex gcc gcc-c++ gettext libtool make patch pkgconfig redhat-rpm-config rpm-build }.each do |pkg|

  package pkg

end

 

So no, its not a problem that calls for replacing yum.  Its a problem with yumgroup and naming conventions.  I see now, that I should have started a separate thread.  All I've done here is unintentionally incite a holy war.  I thought this was somewhat related to some perceived design differences between yum and apt.  Clearly both systems have their pros/cons.  Should yum never evolve, because it meets some stakeholders needs and not others?

You could just use:

yum groupinstall "Group With Spaces"

Sure, but again the end-user has to jump through hoops and use yum inconsistently within a configuration management or automation context.

 

When it is platform version 5 (RHEL5), I could have a shell execute block to do 'yumgroup install "Group with Spaces"'.  But then I would need a separate edge case to handle platform version 6 (RHEL6).  On RHEL6 I would have to also have a shell execute block 'yum groupinstall "Group with Spaces"'.

What's so bad about yum in its current implementation that it should be replaced with apt?  What is so much better about apt?

you've not used apt then :)

 

 

How about all of the time invested in spec files and the rpms that have been built in-house by sysadmins against yum/rpm-based tools for the last decade?  We'll have to go through a learning curve to move to a new build system.

 

Thats the sort of argument that you should ask your redhat sales rep, when he is trying to get you to change from solaris to redhat.

 

You'd probably have to convince the Fedora project to do this as well.  They have an entire ecosystem built on rpm/yum that would have to be ported or replaced.

 

Why? i pay for redhat enterprise linux, i dont pay for fedora support. The way i see it, that redhat has roots in fedora is no more important than its roots in ubuntu (upstart) or debian (name a package) or openbsd (openssh)

 

Seems like a very tall order.

'order' makes it sound like a demand. The question is "how could rhel7 better suit you as a paying customer?" - for me an answer is to scrap yum and rpm in favour of apt+dpkg. For me, the dollars spent on redhat would be more happily parted with.

 

In putting forward what *I* would like to see, i dont factor in what *you* would like to see - thats up for you to do for youself.

sorry, quotes dont seem to work properly.

Thanks for letting us know that, Dean--we'll check it out.

 

Henry

 

Henry Hutton

Community Manager, Online User Groups

Red Hat Customer Portal

hhutton@redhat.com

I'd really like to understand and focus on which features of apt people miss in yum.

 

Eric's example of group installs and meta packages is an interesting starting point, but I am sure it is not the whole story.

 

If anyone on this thread has the time to expand on the specifics, I would very much appreciate the opportunity to build a picture from the contributors here, that we can take back to the Product Management teams for consideration in their planning.

 

Thanks in advance

We had a very unique problem moving our Enterprise Resource Planner (ERP) system to RHEL5 a couple months ago.  The application vendor's knowledge base called for the ICU (IBM International Components for Unicode) source package to be downloaded, extracted into the /usr/local/src tree, and patch a header file to fix an issue with their application.

 

So I enabled the RHEL5 source repo (See https://gist.github.com/870043).  The vendor's own instructions pointed to the use of 'yumdownloader' to grab the package.  Despite the correct formatting of the repo configuration file, yumdownloader would not work.  I hopped onto freenode #rhel channel, and the folks on IRC were able to reproduce the issue, and confirm my repo file was formatted correctly.

 

Compare and contrast to the functionality on Debian-based systems, you would simply run something like 'apt-get source icu' to download a source package.  Certainly not a deal breaker, because I was still able to get the source package by other means.  I don't really take any issue with that utility being broken.  From a usability perspective it manages packages, so why shouldn't that be a sub-command?  Can an issue like the one I've described be identified more quickly by the QA process as a sub-command, or as it stands as a separate utility?

 

I would think it appropriate, if yum were to incorporate more of the utility provided by those functionally separate programs (like yumgroup, yumdownloader) as sub-commands (like apt-get source as an example).  It looks as though it may already be taking this direction, as I see 'yum groupinstall' is a valid sub-command as opposed to 'yumgroup install' on RHEL6.

 

I'm sure that my examples are not the whole story.  I'd certainly like to hear more about the original poster's problems and experiences with yum

This is because there is an issue with using source in the repo name.  Try this kbase I wrote:

https://access.redhat.com/kb/docs/DOC-15838

 

Basically, replace rhel-source with rhel-src or something else.  Should work.

 

~rp

Thanks Robin, that is certainly a weird issue.

Yum is just terrible

Let's step back a bit. What's the problem here? What does yum not do that you need it to? How are you using yum? Where is it falling short?

 

I think it might be better to talk about the problems folks are running into with yum before jumping to a solution.

Reading Eric's post above I think I see the concern.

 

A meta package in apt is easily installable on the cli as if it were just one package, not a bundle of packages.

 

Using Eric's example above:

 

apt-get install "build-essentials"

 

The packages listed in the pseudocode example are only the mandatory packages of the yum group "Development Tools".

 

by default yum.conf defines group_package_types as mandatory and default.  so you would get more packages (including things like systemtap) with the equivalent yum command (and default yum.conf) of:

 

yum groupinstall "Development Tools"

 

This seems to come about because a yum group is not the equivalent of an apt meta package, they are solving subtly different problems.

 

I believe the point being made (Eric please correct me if I am wrong) is that we make developers jump through some hoops where perhaps we don't need to with regard to installing packages from yum groups.

 

apt-rpm.org are working on something akin to the initial proposal of the thread, but switching to apt as the default package manager in RHEL is likely to cause huge headaches for existing scripts and infrastructure.

 

I can see two potential ways to resolve the issue:

  1. Alter Yum's Search Logic
    • add a config option that allows additional searching of group names if a package name is not found
    • call groupinstall internally in yum if that option is set
  2. Ship RPMs composed of dependencies
    • auto compose RPMs based on the output of groupinfo and ship them as: Development-Tools-[Mandatory|Default|Optional]

please bear in mind these are still just ideas to propose the RHEL 7 team.

Either of those would help.

 

With regards to modifications on the search logic, the advantage would be the ability to specify in the yum.conf file the need to install "Optional" packages or not.  Really the "Optional" sets are analogue to the 'apt-get' recommends dependencies.  Those never get installed by a set selection, unless someone explicitly asks for them.

 

With regards to meta-package RPMs, used in concert with role-based configuration management...

 

With either yumgroups or meta-packages, the optional package sets are always going to be the rarely needed edge case.  For example, if I want to install Gnome and X-Windows to satisfy Oracle DB installer pre-requisites.  I would set up a role including those meta-packages "Gnome-Desktop" and "X-Window-System".  I am not likely to need Wacom tablet support from the Optional section of the X-Windows meta-package.

 

If however, I did need something from that loosely related set of Optional packages, such as VNC server from the Gnome meta-package.  Then, I would simply set up a separate role to install and configure such an edge case as VNC.

Just FYI, Linux Standard Base (LSB) refers to RPM and not alternative formats.

Almost certainly, any feature deltas can be filled quickly.

 

The question is though... does RedHat want to continue maintaining a less popular package format and management system?

 

Does redhat want to reduce the learning curve for new users, which lets face it, are starting out on ubuntu or linux mint.

 

A clean break on rhel7 allows RedHat to stop duplicating package management tools and start spending time thinking up new features.

 

I will also argue that if yum+rpm is to be continued, then the authors/maintainers shouldnt be 'waiting for customer requests' - they should be proactively copying features from other package management systems and thinking up new ones.

 

Infact, that is the biggest criticism i have for redhat is their 'ask and we will think about it if you can provide a business justification' - rather than seeking to continuously polish, bring in neat new features which appear in similar tools and also come up with new features.

I respectfully disagree. I do not want anyone installing software on my boxes if they do not know how to use man pages and is not decently familiar with multiple package managers. The idea of a fresh Linux Mint user dropping to a root shell and installing software terrifies me. Learning in Ubuntu/Mint is great and I definitely promote that but if you are serious enough about linux to want to start a career with Linux, I expect you to be very prominent in it. Someone doesn't have familiarity with the tool, no worries, but they had better know where to figure it out, and be capable of figuring it out quickly, on their own. I just don't see RPM/YUM being that complicated. These same people will be managing LVM, working with perl scripts, hardening the boxes, and configuring various servers. If they can't learn RPM/YUM they have no place in such an environment.

 

This also doesn't mean that I am hard on newcomers. I am simply hard on people who wish to have a technical job but lack the technical skills and desire to learn.

 

That said: I certainly agree with you as far as your last paragraph goes. I believe Red Hat should always seek improvement, and I have not seen that. I could come up with some ideas for bettering YUM/RPM, which in my opinion is a far better idea than adopting a separate package manager. RPM is, after all, the Red Hat Package Manager...

Yum is a great package manager and always has been, I also enjoy the extensions that were added in rhel 6.  Apt software management is for debian based (NON ENTERPRISE) Linux distros, anyone serious about using a production enterprise grade Linux solution needs to learn YUM.  RPM has been the standard redhat based package type for ever and works great, no reason to ever consider deb packages.

Hi,
I can not understand this discussion. RPM (Red Hat Package Manager) incombination with yum is a great tool.

Above all, it's reliably, fast, clear and easy to handle.

In addition, the entire build system is based on RPM. (mock, koji, rpmbuild, RHN)

Furthermore, you get detailed information about packages with RPM. (For example: build host, build date, version, release, changelog, etc..)

As both Red Hat and Debian packager I have to say that I like the RPM packaging format a lot. It is certainly subjective, but the time it takes me to maintain hundreds of SPEC files is comparable to what it takes me to maintain dozens of Debian packages (the format is very complex, policy is quite extensive and has corner cases etc.).

 

I think the whole discussion was started from the wrong point. Yum has its problems as a package manager and it makes much more sense to indentify and solve them, or alternatively consider apt-rpm, rather than suggesting to change the packaging format out of the blue.

"I think the whole discussion was started from the wrong point. Yum has its problems as a package manager and it makes much more sense to indentify and solve them, or alternatively consider apt-rpm, rather than suggesting to change the packaging format out of the blue."

 

Agreed.  One of the few sensible posts, in what turned into a package format holy-war thread.

My original post should have focused on the non-technical merits of adopting apt-dpkg. Which is simply...

 

The drop three out of five distros* use apt-dpkg. New linux users are overwhelmingly (99%) using ubuntu or linux mint. Even in the redhat shop i work at, our admins all run ubuntu, debian or mint desktops.

 

Based on this, i propose that RedHat would significantly reduce the learning curve for new users. Thereby also reducing the barriers to adoption of the RedHat Enterprise Linux product. This would be a significant win for the RedHat sales force.

 

There are other minor benefits, such as reduced development. And there is no doubt that apt+dpkg is mature and fully featured, you are not swapping a calligraphy set for crayons by using it.

 

 

(* according to distrowatch, not a scientific source)

 

 

I am glad that this tread has gotten so many responses. Hopefully this means that people are thinking, and if they are thinking then they are innovating, and if a companies employees are innovating - there is more chance it will succeed. If they aren't then it will certainly fail.

 

Unfortunately there are a number of disappointing "this thread is pointless" type comments. Shame on you for trying to squash discussion. If you are so assured of your package manager of choice then you would invite lively discussion and enjoy the rigoress debate.

> Based on this, i propose that RedHat would significantly reduce the learning curve for new users.

 

There is no learning curve to using a package manager for basic system administration.

 

It's a matter for spending 15 minutes to read the manual and learn basic commands which are actually the same for both yum and apt (install, remove etc.). Learning to use apt correctly is actually much more complex in this regard (--purge option, update updates the metadata, not the system, dep-resolved update is called dist-upgrade etc.), although of course it brings a lot of flexibility, some of which yum is supposedly still lacking. If this something that an administrator can not or is unwilling to afford, I would question if he has chosen the right career track in the first place...

 

That being said, I'm not against apt as such. RPMForge has been providing apt metadata for a very long time and I used apt quite a lot to keep my Red Hat systems up to date. However, apt-rpm is now unmaintained, and yum is consistently getting better, so I don't regret switching to yum at all, even though in some intelligent design meta-sense probably, all distributions should at some point converge to one GRUMP (GRand Unified Manager of Packages).

 

To make a point, to my mind one would start by collecting examples where yum is being counter-intuitive, limited and hard to understand. There've been some valid examples brought up in this thread already. I'm sure there is a lot of room for improvement.

 

Bonus idea: how about developing a set of aliases i.e. alias apt-get dist-upgrade = yum update etc. ? Maybe a KB article for apt-get <-> switchers would be quite appropriate.

IMHO yum is clearer and easier than apt (which is why I prefer aptitude on my deb systems). It's one command instead of several (and not always entirely clear which one should be used), the command-line options are more consistently organized (e.g. apt-get --just-print updates vs yum list updates). Also yum plugins are very nice indeed. And the output of yum is very clean and organized and easy on the eyes.

 

Of course it's a subjective point but as a long-term user of both, I really think neither has a huge advantage over the other, both do the job, and people's preference here is usually down to what they are more used to rather than real concrete issues.

 

Making such a big change isn't really worth considering unless numerous serious unfixable problems with the existing tool are laid out first. And I don't think it would be a good idea to provide both - I wouldn't appreciate the pointless confusion it would create in manuals, training, inconsistency in people's scripts, etc. At best stick apt in an "unsupported" channel, or just let people use rpmforge.

Absolutely agreed. No one should maintain a linux system if they cannot use a package manager. I'm used to installing from source; if you can't manage a simple yum/rpm/dpkg/apt-get command you have no place in Enterprise Linux administration. It's not really that complex, if it takes you longer than an hour to be comfortable and quite familiar with yum/rpm, there is a problem.

 

And from my experience, having spent many years on Debian and Ubuntu using apt-get, and a few years on RHEL using yum, I'm much more pleased with yum. Yum seems very straight forward and the commands are such that anyone could very easily use them. If anything, apt-get is where you'll find the learning curve, IMHO.

Ok since the various RHEL's come from Fedora, and this change would require a complete overhaul of the installer, the build system, the mirroring system, the packaging methodology etc.. it would need to be done up there first to see if it could work.

 

While you might be able to say "use Debian" for upstream, it would still require a bunch of changes as how Debian lays out items and how Red Hat has traditionally laid out items are very different. [And while the changes with Fedora's systemd will initiate a LOT of changes, it is still less than the Debian/RHEL delta.]

If you want to install yum groups without using spaces you should look at the output of:

  yum grouplist -v

 

this will dump out a name in parentheses which is the group id. For example:

Development Tools (development-tools)

 

That option is listed in the grouplist section in the yum man page.

 

now, with this information you can just do:

 

yum groupinstall development-tools

 

or if you don't have any issue with an @ (which most languages/shells do not have a problem with):

 

yum install @development-tools

 

if you want to enable optional-package installation you would do:

 

yum --setopt="group_package_types=default,mandatory,optional" install @development-tools

 

group_package_types is a configuration option which is documented in yum.conf (where it can be set under [main] if you want to set it permanently)

 

As to metapackages - fedora and epel already have some look at the 'git-all' package, for example. It's just a metapackage. 

 

Additionally, yum has many new features in rhel6 that were not available for rhel5. You would be benefitted by looking into them. 

 

Some specific new features:

yum history: http://yum.baseurl.org/wiki/YumHistory

 

yum db: http://yum.baseurl.org/wiki/YumDB

 

Another feature of yum-utils which is often overlooked: 

 

repoquery: http://yum.baseurl.org/wiki/RepoQuery

 

 

these three tools, alone, allow yum to access a lot more information and do a lot more than other package managers available.

 

If you have questions about how to use these tools or suggestions for documentation, there is a yum mailing list available at:

http://lists.baseurl.org/mailman/listinfo/yum

 

It is run by the great folks at osuosl.

 

Additionally, you can often find the yum developers and users in #yum on freenode. 

 

 

Thanks

-sv

 

 

   

I do not see a technical need.

 

yum list available can give users an idea of which rpm's are available to them.

 

Most cases I have seen where people complain about missing functionality is when they lack the channel subscription.

apt will not solve that issue.

I also don't see the point. For all our junior admins, I have been telling them to skip Debian/Ubuntu and go straight to Fedora/CentOS for learning.The majority of our Linux deployments are RHEL!

I know this is not the right place to get it fixed but I think it fits in to the discussion.

 

- The time it takes to get an answer from yum search

- The missing possibility to do yum search or yum grouplist while yum update is running

 

To be honest, I hate waiting on small things.

If YUM could get faster I would really be happy.

Commands, Subcommands, Options, Arguments can all be learned but waiting seconds to get a list of packagenames is annoying.

 

And of course fix the locking for read only operations.

 

Just my 2 cents.

Christian

I can't argue this.  But I may have a solution for you. :)

 

I run RHEL6 on my personal and work laptops.  I install  most third party repos.  These include:

 

ATrpms

ELrepo

EPEL

RPMFusion

 

I then run:

 

# yum list > yum-list.txt

 

After this, I disable all third party repos and use --enablerepo=repname to install third party packages.

 

But, I do this so I can instantly search for the packages I need.

 

$ grep PDF ~/yum-list.txt

perl-PDF-Reuse.noarch             0.35-3.el6           rhel-x86_64-workstation-optional-6
perl-Text-PDF.noarch              0.29a-2.1.el6        rhel-x86_64-workstation-optional-6

 

Hope this helps.

 

:)