“rPath’s Conary is a second-generation package manager. Considering that Erik Troan, rPath’s CTO and co-founder, was one of the original authors of the RPM package format, some might be tempted to view Conary as an effort to do things right the second time around – nor is that view far from wrong. In its design, Conary is a streamlined version of dpkg or RPM with Yum in which all the utilities of those package managers are combined in a single command and combined with version control to meet the demands of a modern distribution.”
For me it seems a little overkill and complicated. It doesn’t seem to be solving a real problem either. I’m happy with yum and apt-get.
System
Syndrome
Brooks, once again, was right.
Sounds terrible. When I read “innovative second generation package manager” I expected more than a yum+dpkg wrapper. There’s nothing wrong with yum or apt-get in the form they’ve reached. They’re stable and mature. If they really want to innovate they should think of something, you know, new.
Quote from article:
“Although almost everyone who encounters Conary is enthusiastic about it, no major distributions are apt to swap out their existing package systems in order to adopt it.”
The reviewer should read more before saying this.
Conary is way ahead of yum, apt, or rpm.
That’s why AsteriskNOW (a *major distribution* from Digium) has based it’s distribution on rPath, and others like “SugarCRM”, “OpenFiler”, etc., have followed
I’ve been using Foresight for about three months, and it’s a delight, without dependency hell on package management. rPath feels “Correctly Built”, instead of “Plastered Together”, like most other Linux distributions.
kwag: I’ve been using Foresight for about three months, and it’s a delight, without dependency hell on package management. rPath feels “Correctly Built”, instead of “Plastered Together”, like most other Linux distributions.
I’m not saying that Conary is bad, but can we please get over the “dependency hell” chimera? There is no such thing like dependency hell, at least not any more. Every major package management system (i.e. apt/dpkg and rpm) deals with dependencies in a mature and reliable way.
Nobody can help you if you want to compile your own programs and you don’t read the requirement list beforehand.
One should probably try it before making an opinion.
The article doesn’t go deep enough. I didn’t see any real difference with aptitude, but I’m sure there are many.
B. Janssen: “There is no such thing like dependency hell, at least not any more. ”
And on what planet would that be?
“””
And on what planet would that be?
“””
I work a great deal with systems running Fedora, CentOS, and Ubuntu. And I must say that for the last several years I have been a bit puzzled when people start going on about dependency hell. Sure, there are a lot of interdependencies, but the package managers handle it so well these days that I rarely have to pay attention.
In particular, with Ubuntu it sometimes seems as though all I have to do is *wish* a package onto a system and it’s there.
In fact, I went to install a third party package with gdebi (mozilla plugin) the other day, and even gdebi worked out that another package was needed and offered to install it.
Anyone who is still having dependency problems (if such people actually exist) needs to write some stern words to their distro’s maintainers or find a distro that isn’t stuck in the 90’s.
Agreed. I’ve yet to have a case these days of dependency hell, but I have had cases of “dependency heck” — the milder form once every blue moon on Ubuntu.
I tried installing a package (I can’t forget which one) from universe a month ago and found that it depended on version CVS of a package (that’s what the package name was called) but only version N was what was available because another more popular package depended on it. I had to download the CVS version of the DEB manually (apparently it wasn’t included in universe because it conflicted with version N).
Granted, universe isn’t officially supported, but I’m willing to bet that both conflicting packages could have worked for either or it would have been possible to set up different installation directories and environment variables and have them both be installed. It’s possible to do both with configure-make scripts and often possible to do with binaries (if they don’t hardcode paths), so it’s clear that apt-get isn’t ideal.
I don’t know if Conary solves this problem though since this issue occasionally trips up even source based Gentoo if you install masked packages.
Granted, universe isn’t officially supported,
And you don’t think that would be related to your problem?
Mixing stable with unstable (includes non-official repositories) is likely to cause trouble – no matter the OS in use.
Being always interested in online security, and frustrated with all the poor security nowadays, one of the the first things that comes to my mind when reading about new package management schemes is: how secure it might be? Or is the security of Conary related more to each individual implementation and a distribution?
Now that we have secure apt-get (Debian, Ubuntu) and other such relatively secure package managment solutions, I’m just not willing to compromise and go back to less secure solutions again. (However, OpenBSD might be a bit too much for me as a daily desktop OS though…)
Yeah, well, maybe I might be a bit paranoid to take this point of view here… – but ever heard about rootkits, spam, viruses, spambots, crackers etc…? At least I would like things to be a bit better than what they are, wouldn’t you? Improving package managemnt security is one part of the bigger picture in IT security. And yeah, I do know that even a bit less secure package management systems than, for example, secure apt, may well be secure enough especially for ordinary desktop users. But – why bother to use and support anything less secure if you do have more secure (and even quite easy to use) options, and why take any extra risks?
So, does Conary, Foresight and/or rPath address potential security issues in package management in any way? Do they use signature checks (repositories, packages) or something like that? Or is security a concern for them at all?
(Edit: corrected a few typos etc.)
Edited 2007-03-06 20:00
I think ther posters here, and the article misses the biggest feature of conary: The integration of distributed version control and source built packages.
It’s like the nice features of a source based package manager like portage, married with a distributed version control like git and it even keep tracks of compiled packages like apt.
I mean it seems to be a perfect fit for the open source development model.
Then again, I haven’t actually used the beast. But seriously you can’t really compare it to a apt or yum only.
I do think a better implementation could build on the infrastructure that’s allready in place though. A mirroring and distribution system for git,darcs,bzr and friends. Some additions to the build systems to better integrate with modern package installation systems and a move towards a global namespace for dependency managment.
For global dependency to work we must device a way to depend on interfaces rather than implementations though.
I’ve always been curious about conary and forsight linux but never really had the time to try it, might have to give it a download and see what all the fuss is about.
From the article it’s difficult to determine what exactly conary solves if anything. I’m going to find out for myself. I’ll post a reply to this with my findings.
Edited 2007-03-07 14:31
“From the article it’s difficult to determine what exactly conary solves if anything.”
http://wiki.rpath.com/wiki/Conary:Concepts
yes, i am well aware of the rpath website, i was simpley speaking of real world advantages vs’s advantages on paper whiich often conflic.
I’m talking speed of installation, quality of installation, stability, dependency issues…. etc..