Why I don’t like Conary, the first edition

Thursday 11. January, 2007

(I was going to write this as a response to a comment on an earlier post but I thought this would make a nice posting)


Conary is a package manager software, like dpkg+apt-get in Debian/Ubuntu (and so on..) or RPM+yum/SmartPM…. The difference to tradiotional ones is that Conary has integrated repository and it doesn’t have external wrappers around repositories like apt-get or yum. Conary is written in Python (entirely?).

Answer to question “What issues did you have with Conary”:

I already had over 600 RPM specs for one thing (of which about 200 are generated by a script, does X.Org ring a bell?) (This, of course, is not Conary’s fault)

The way Conary repositories are handled… I got that impression that there’s no way to remove packages from the repository, which makes it “quite big”, if I have to rebuild packages 1) when updating and 2) when I notice (too late) that something is wrong in current package or 3) if have included a package that has legal troubles, how do I get rid of it without rebuilding the whole repository?

I guess that all *possible, future* mirrors would have to be running Conary service, which would limit the number of server candidates to near zero.

Setting it up isn’t the easiest task, especially when made from Ubuntu.

Creating new package recipes does seem to be easy, but then I got fed up with all these build policies. My initscript package ended up having not a single working script as all symbolic links were screwed, when the policy changed things to the “RedHat-way”. And it also required chkconfig(?) lines into the scripts, but LFS doesn’t contain such a thing. And it seems that Conary wiki has no information on how to change policies with exception of just making exception definitions into recipes, which doesn’t seem right and sustainable. (I can modify RPM to have some kind of package cleaning policy in post-spec-build macros and it’s not hard)

Of course there’s other (and even better) ways to build a Conary-based distribution as suggested in the Wiki (Installing a Conary-based distribution and modifying it from there…), but that would drop out the LFS and even BLFS to limited extent.

Don’t misunderstand me, Conary does have nice properties such as simple recipes, but sometimes there’s little things that make it undesirable.


One Response to “Why I don’t like Conary, the first edition”

  1. Conary policy is overridable by checking out conary-policy and modifing it as needed. It was designed to be “pluggable”, in that each distro could modify without having to change conary proper. We (rPath Linux) require chkconfig lines in initscripts because chkconfig manages our boot process… if you have something else to do that for you, then it would be entirely appropiate for you to change the policy. Policy is designed to make packaging *easy* for the end-user, and once you get used to it, its a godsend.

    Conary does not store data in the repository in the same manner in which yum/rpm does. Instead of imaging a tree of files on a website, imagine something more like CVS or SVN. With every new version you commit, conary only stores the changes. The changeset you install or download is dynamically generated. Thus if you have package foo of version bar and you update to version baz, and most of the files stay the same (they usually do), then you’ll not be storing multiple copies in the repo, nor will you need to download them on update.

    As for removing things from the conary repository, it *is* possible, since conary 1.1 (rather, a server running 1.1.x). However, since conary has a distributed development model, it is generally not good to remove things from underneath other developers. As such, we do not advertise this feature, but it is available for extreme cases like cease-and-desist orders or any other legal issues (or mistakes, if you catch them quickly enough).

    And lastly, mirrors. You are right that few places offer conary mirroring services. However, due to the way conary works, oftentimes they are not necessary. rPath hosts all of rBuilder Online, rPath Linux, Foresight Linux, and many more, without that much hardware requirements. Mostly this is due to how for any given update, conary takes a small fraction of the bandwidth of yum/rpm (when updating the manpage for openoffice, rpm requires an 80m download, conary about 150k, for example). The real requirement here is bandwidth for install media and/or live images (vmware, qemu, parallels, livecd, and so on). Those, however, are not managed by a conary repository directly. They are flat files which can be mirrored and hosted by anyone with a web server or ftp site. rPath, for example, hosts all such files on amazon’s s3 service, with great success.

    If you have any questions or comments, you should jump on #conary on irc.freenode.net. We’d love to hear more about what problems/issues you had so we can either fix them or document why it is like it is 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: