Projects / Conary


Conary is a distributed software management system for Linux distributions. It replaces traditional package management solutions (such as RPM and dpkg) with one designed to enable loose collaboration across the Internet. It enables sets of distributed and loosely connected repositories to define the components which are installed on a Linux system. Rather than having a full distribution come from a single vendor, it allows administrators and developers to branch a distribution, keeping the pieces which fit their environment while grabbing components from other repositories across the Internet.

Operating Systems

Recent releases

  •  21 Jan 2013 03:58

    Release Notes: This release adds --replace-modified-files, --replace-managed-files, and --replace-unmanaged-files options to the "conary rollback" command (CNY-3748). The --replace-files option is now deprecated. Scripts should use the more specific options (CNY-3763). This release fxes createSourceTrove conflicting with markremoved troves when choosing a new version (CNY-3771).

    •  15 Apr 2010 04:10

      Release Notes: Internal changeset loading has been adapted to avoid a large spike in memory use.

      •  15 Apr 2010 04:02

        Release Notes: Conary now allows packages to be installed using foreign package managers via wrapped content called capsules. RPM capsule support is included in this release. Other features are support for xz compression, better dependency resolution, support for cpio archives, and much more including many bugfixes.

        •  02 Nov 2007 21:49

          No changes have been submitted for this release.

          •  02 Nov 2007 18:27

            No changes have been submitted for this release.

            Recent comments

            07 Apr 2005 10:48 gvy

            Re: Errr.... concept level mismatch?

            > Okay here's a thought - you obviously

            > don't "get it", and this leads me to

            > believe that you clearly have yet to

            > experience Conary

            Yep, I don't "get it". Mind you, I'm both systems administrator, maintainer of some 100+ packages, and doing/using quite some mirrors, 3rd party repositories and so on. Somewhat working on distros and branches management also. Still don't.

            > so why not downoad a

            > distro that uses it, such as Specifix or

            > Foresight, and actually have a good look

            > at it before giving us all the pleasure

            > of your ill-informed review?

            Hm, and why download distro which seems to be announced as "still immature" proof-of-concept if *two* quite different build systems on top of apt-rpm I'm using right now to *exactly* build distributions -- both tweaking desktop one and creating server appliance one -- and things Just Work, with these technologies being mature and established? Just for respect for Erik Troan? No thanks, I owe Red Hat quite a few users with "full install" illness.

            RPM and dpkg don't contraverse "loose collaboration" to me, so there's no sense to junk them (instead of building on top). Production doesn't mean Gentoo and similar approaches to me too just because it's *too* loose.

            Yes, I've initially missed the "embedded" word in positioning of Specifix; but hey it's not anywhere in Conary's CV, maybe the description should be updated.

            And yes, I've read several documents on project's site before getting my ill-informed comments here. Just because there's no good reason to reinvent the very basic wheel when there's more reason to focus on higher-level issues of package [cluster] management, I'd better spend that time looking on Smart ( Maybe one day our building systems will get ported to that.

            PS: please don't take it too personally, just so tired with splintering and reinventing that happens all the time anyways... Good luck if it works for you, I'll just have to cope with my ill-born toys sitting two conceptual levels higher. :-)

            07 Apr 2005 09:47 Gilesx

            Re: Errr.... concept level mismatch?

            > Did you ever see apt or yum tools?


            > If the description is correct then

            > you're trying to solve the problem at

            > the wrong level (and it's already solved

            > long ago, just in case).


            > It may well be the case for RH users but

            > the rest of the world wasn't staying

            > with basic package management when the

            > most abstract thing is a package -- it's

            > OK but people need more, so package

            > repositories and tools to handle

            > collections of packages were

            > (re)invented.


            > But see: it's a different layer, they

            > didn't throw lower-level tools like rpm

            > and dpkg out of the window since they do

            > their job at their level reasonably

            > well. It's just that it's not their job

            > to operate at a higher level.


            > Re "loosely connected": you loose indeed

            > at least on library version hell (the

            > price is synchronization efforts by

            > version bloat, the more efforts or

            > versions, the more chance for such thing

            > to work). Or is there some other

            > solution within precompiled binary

            > package paradigm?

            Okay here's a thought - you obviously don't "get it", and this leads me to believe that you clearly have yet to experience Conary, so why not downoad a distro that uses it, such as Specifix or Foresight, and actually have a good look at it before giving us all the pleasure of your ill-informed review?

            22 Sep 2004 00:05 gvy

            Re: Errr.... concept level mismatch?
            Roundup: if Conary solves the problems something has introduced to you, that's fine. I'd just to remind you that doing things which will virtually never be accepted upstream is a significant waste of time, and for software management system it means at least "widely accepted in appropriate software community".

            But if there's a community to talk about, it should be better off fixing real problems not building the workaround scaffolding, as discussed in previous snippet.

            Regards anyway.

            22 Sep 2004 00:00 gvy

            "Real-life problems" revisited

            Continuing on "real-life problems"...

            Re versions, you have to tag different builds of the same upstream source (e.g. mozilla-1.7.3) with different patches or configure keys and maybe a different build environment altogether. So why you call build tags "hacks" but then reinvent the bigger and better wheel with (auto-)assigning longer versions and then crumming them down to be "like usually"? ;-)

            Re "files being replaced", it's exactly what I've talked above -- braindead upstream packaging of a given package. Even RPM has quite developed system for marking files as "%config(noreplace)" to simply put the newer versions aside if the file in question *has* changed ("quite developed" since there are another interesting possibilities, including what's to determine its "changedness"). (and yes, if you need to patch an initscript, that's the same diagnosis: the packager should have provided some configurable include to modify instead of hardwiring things into a script)

            Re permissions, at least ALT Linux (you seem to have looked at that, right? ;-) and Owl GNU/*/Linux use control(8) system to support persistent and replicatable state of permissions (originally; in fact, much more) of controlled files. It's a very simple and reviewable set of shell scripts which is quite self-contained and adding the support to the package means creating and packaging one more file and calling update scripts in %pre/%post.

            That's quite convenient for sysadmins, and some of them add control scriptlets of their own for things they like to have controlled.

            Re "changing what's really changed" -- SuSE has developed "patch RPMs" (which were recently discussed in devel@altlinux too) to carry over only the changes since the base version; it may be reasonable for security updates with monsters like desktop environments or integrated applications traffic/time-wise but doesn't help much in development environment.

            Re kernel modules -- what if the kernel packaging system allows for building and packaging modules independently ( as well as maintaining the kernel patches in a definite form so that it's possible to improve the "fix"/"feat" package and have a kernel rebuild with no effort? (heck, I'm known in local communities for teaching people *not* to waste time on building kernels but to choose the proper distros where Things Just Work ;-)

            All in all: choose proper distro, be it Debian, SuSE, Fedora (?), ALT or whatever team listens to you and fixes the bugs and allows you to add features that may be beneficial to the wider community. It's more productive than "fixin' a hole where the rain gets in, \ stops my mind from wonderin'..." :-)


            21 Sep 2004 23:31 gvy

            Re: Errr.... concept level mismatch?
            Uff... One of the problems Conary solves is indeed inadequate and overly in-house RedHat's approach to package repos of the past. You talk of "local changes" but if they're persistent, wide-scale and generally reasonable then they belong to the upstream repository as either bugfixes or enhancements. To achieve that, upstream ought to be listening to you (or me, or the fellow administrator doing local changes).

            *That* is a problem, but it's organizational one, not technical. And the whitepaper's author seems to understand that as he mentions things "...not designed to facilitate forking" but that's exactly what they get used for: persisting difference from upstream instead of fixing that.

            Please get me right, I'm not blaming you for the software, I'm (yes,) blaming you for trying to fix a braindead thing: it's like patching Sendmail or BIND8 instead of throwing it out of the window and getting more straight approach implemented.

            If the upstream doesn't work, fix it or change it.



            Project Spotlight


            A Fluent OpenStack client API for Java.


            Project Spotlight

            TurnKey TWiki Appliance

            A TWiki appliance that is easy to use and lightweight.