Language Selection

English French German Italian Portuguese Spanish

Your rPath to Conary

Filed under
Linux
Reviews
-s

Development Release: rPath Linux 0.51 (Alpha) was announced by DistroWatch yesterday, and I was a bit curious. After my first glance, I was a bit taken aback. rPath doesn't seem to be targetting desktop users. Although it ships with KDE and Gnome, they aren't the most up-to-date versions, nor are they dressed up or enhanced in any manner distinguishable. In my humble opinion, I think rPath is probably a developer's platform, ...a conary developer's platform.

Information about rPath, as well as its ancestor Specifix, is fairly sketchy. The rPath website is a page listing a job opening and a link to the conary wiki, however DistroWatch states "rPath is a distribution based around the new Conary package management, created by ex-Red Hat engineers, to both showcase the abilities Conary provides and to provide a starting point for customisation." The conary wiki is pretty thin itself, although I was able to gleen a little information from it.

It was no big surprise to see (a modified) Anacoda as the installer and (as usual) I found it fairly straight forward and easy to complete. It asks some basic configuration questions such as network setup, firewall choice, and bootloader conf. I must say I loved the package selection portion. One is give one choice: everything. Could it be any easier? It takes a little while to install and once it's complete, it reboots without setting up other hardware or user accounts. Upon reboot it starts X as root, but to complete some other basic configurations in a graphical environment using rPaths Setup Agent. Included configurations include the date and timezone, monitor and resolution, and of course user account(s). Upon Finish, it restarts X and presents gdm for login. KDE and gnome are about your only choices for a desktop environment/window manager. rPath includes KDE-3.4.1 and Gnome-2.10.2. The Xserver version is xorg-6.8.2, gcc is 3.3.3, and the kernel is 2.6.12.5. The kernel-source isn't installed from the iso, but one can install it with conary.

        

Conary is rPath's package management system. As it appears conary is the focus of rPath, I spent quite a bit of time trying to figure it out. I began my quest quite lost and confused and ended it a little less lost and confused. According to the site, "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." Simply put, it's the package manager. It appears to be able to obtain packages from different repositories, utilizing binaries if available or sources if necessary and storing all versionings in a database in order to track changes from source branch all the way back to local versions installed on a given system to meet dependencies without conflicts.

According to the wiki, after the installation of rPath 0.51 the first thing one should do is update conary to version 0.62.2. Termed Conversion, the instructions stated to issue the following commands:

$su -
# conary update conary
# conary q conary
$ su
# sed -i 's/lockTroves/pinTroves/g' /etc/conaryrc

They continue with instructions in case an AssertionError is encountered. I didn't experience such an error and proceded with reading the wiki, --help, and man pages.

Conary at the commandline appears very apt-like. In fact the conary-gui is identical in appearance to synaptic. The gui front-end didn't seem to function very well here, but the commandline version seems to work as intended. Also included is the utility "yuck" which is a wrapper script to call conary --upgradeall.

        

Fortunately running conary is much easier than trying to understand what it is or how it works. Some simple commands include: conary q <packagename> reveals if the given packagename is installed, whereas conary rq <packagename> lists the newest available upgrade. conary update <packagename> installs or updates requested packagename, and conary erase <packagename> uninstalls. There are many many interesting options to play with in using conary beyond those basics, but most seem to geared toward package builders. Some of these include emerge, which builds the "recipe"; commit, which stores the changes; and showcs, which shows the difference. It really looks sophisticated and yes, I admit, a little complicated at the more in-depth level.

So, to install the kernel-source, one simply types: conary update kernel-source

The developers might be onto a superior package management system, but is it catching on? We know rPath obviously uses it and I understand Foresight Linux to utilize this package management system. As for rPath, it was a stable functional development environment. It seems it isn't trying to be the latest or greatest nor the prettiest. If you are interested in developing for conary or wish to use a system utilizing that package management system, then rPath might be the distro for you. The full package list as tested is HERE.

        

Conary

I'm pretty hazy on this too, so I might be completely off, but here is how I understand this:

While to a casual user Conary looks pretty much like apt-get or synaptic, it does do something more advanced under the hood. It is intended to make it easy to put together a system using a number of separate and *independent* repositories, each making its own changes and mini-releases. Conary tracks not only what you installed on your system, but also where it came from. This extends to any dependencies it uses, and it becomes quite a powerful concept.
For example, Foresight which also uses Conary is actually created largely from packages pulled directly from rPath repos; I would say as much as 75% of packages are not modified at all. If you install Foresight and later run updates on it, you'll see number of packages are updated from rPath repos. Any packages Foresight guys developed themselves come from their own repositories, naturally. But any packages that do exist in rPath but were modified in Foresight are overlayed over the 'standard' versions, with Conary keeping track of what comes from where, and what depends on what (in that context). This is pretty cool for Foresight guys, who can make their own distro while at the same time take a lot from the base, rPath.

Think of it this way: if you used Fedora, you probably tried at some stage to add various third-party repos to your yum config: Livna, Freshrpms etc... and quite possibly you discovered in the process some of them can conflict with others... it can become a mess. Well, this is exactly the situation Conary adresses.

... but again, I could be completely wrong.

re: Conary

That's pretty much the way I understand it as well, in that conary can keep track of any and all changes to the branches of a given source from the main branch all the way to minor revisions on public mirrors as well as on your local machine (which is especially good for developers). An end user can choose to install any version listed or just go with the latest. Like other package managers, all depends on the repositories set up tho. Good explanation! Thanks for your contribution. That's wonderful.

-s

----
You talk the talk, but do you waddle the waddle?

Conary

You are correct that rPath is developmnent release for the extensive testing of the Conary system, fPath is from Specifix who is the creator of Conary. Other distros like Foresight have taken and used it for their own needs. I find the Conary system interesting and quite functional, but have not made a decision about it's need and potential in the comunity.

My 2cents,
Capnkirby

re: Conary

I think it's a wonderful concept as well, but I think it'd be rather complicated to set up and most developers are already set in their ways. And when you factor in how few distros use that method... I don't think it's something that will catch on right away.

----
You talk the talk, but do you waddle the waddle?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

More in Tux Machines

Digital audio and video editing in GNU/Linux

  • Linux Digital Audio Workstation Roundup
    In the world of home studio recording, the digital audio workstation is one of the most important tools of the trade. Digital audio workstations are used to record audio and MIDI data into patterns or tracks. This information is then typically mixed down into songs or albums. In the Linux ecosystem, there is no shortage of Digital audio workstations to chose from. Whether you wish to create minimalist techno or full orchestral pieces, chances are there is an application that has you covered. In this article, we will take a brief look into several of these applications and discuss their strengths and weaknesses. I will try to provide a fair evaluation of the DAWs presented here but at the end of the day, I urge you to try a few of these applications and to form an opinion of your own.
  • Shotcut Video Editor Available As A Snap Package [Quick Update]
    Shotcut is a free, open source Qt5 video editor developed on the MLT Multimedia Framework (it's developed by the same author as MLT), available for Linux, Windows and Mac. Under the hood, Shotcut uses FFmpeg, so it supports many audio, video and image formats, along with screen, webcam and audio capture. The application doesn't require importing files, thanks to its native timeline editing. Other features worth mentioning are multitrack timeline with thumbnails and waveforms, 4k resolution support, video effects, as well as a flexible UI with dockable panels.
  • Simple Screen Recorder Is Now Available as a Snap App
    Simple Screen Recorder, a popular screen recording app for Linux desktops, is now available to install as a Snap app from the Ubuntu Store.

Kernel News: Linux 4.10 in SparkyLinux, Wayland 1.13.0, and Weston 2.0 RC2

  • Linux Kernel 4.10 Lands in SparkyLinux's Unstable Repo, Here's How to Install It
    The trend of offering users the most recent Linux kernel release continues today with SparkyLinux, an open-source, Debian-based distribution that always ships with the latest GNU/Linux technologies and software versions. SparkyLinux appears to be the third distro to offer its users the ability to install the recently released Linux 4.10 kernel, after Linux Lite and Ubuntu, as the developers announced earlier that the Linux kernel 4.10 packages are now available from the unstable repository.
  • Wayland 1.13.0 Display Server Officially Released, Wayland 1.14 Lands in June
    Bryce Harrington, a Senior Open Source Developer at Samsung, announced today the release and general availability of the Wayland 1.13.0 for GNU/Linux distributions that already adopted the next-generation display server.next-generation display server. Wayland 1.13.0 has entered development in the first days of the year, but the first Alpha build arrived at the end of January, along with the Alpha version of the Weston 2.0 compositor, including most of the new features that are present in this final release that you'll be able to install on your Linux-based operating systems in the coming days.
  • Weston 2.0 RC2 Wayland Compositor Arrives With Last Minute Fixes
    While Wayland 1.13 was released today, Bryce Harrington today opted against releasing the Weston 2.0 reference compositor and instead issue a second release candidate. Weston 2.0 is the next version of this "playground" for Wayland compositor technologies since the new output configuration API had broke the ABI, necessitating a break from the same versioning as Wayland.
  • [ANNOUNCE] weston 1.99.94

KDE Leftovers

  • Fedora 25 KDE: disappointing experience
    Fedora is not a frequent guest on the review deck of Linux notes from DarkDuck blog. The most recent review was of Fedora 22 back in July 2015. That was a review of the GNOME version, the most native for Fedora. You are probably aware of the tight link between the GNOME project and RedHat, the Fedora Project main sponsor.
  • [Video] Ubuntu 17.04 Unity 8 - KDE apps native on Mir
  • Plasma in a Snap?
    Shortly before FOSDEM, Aleix Pol asked if I had ever put Plasma in a Snap. While I was a bit perplexed by the notion itself, I also found this a rather interesting idea. So, the past couple of weeks I spent a bit of time here and there on trying to see if it is possible.
  • QStringView Diaries: Advances in QStringLiteral
    This is the first in a series of blog posts on QStringView, the std::u16string_view equivalent for Qt. You can read about QStringView in my original post to the Qt development mailing-list, follow its status by tracking the “qstringview” topic on Gerrit and learn about string views in general in Marshall Clow’s CppCon 2015 talk, aptly named “string_view”.
  • Making Movies with QML
    One of the interesting things about working with Qt is seeing all the unexpected ways our users use the APIs we create. Last year I got a bug report requesting an API to set a custom frame rate for QML animations when using QQuickRenderControl. The reason was that the user was using QQuickRenderControl as an engine to render video output from Qt Quick, and if your target was say 24 frames per second, the animations were not smooth because of how the default animation driver behaves. So inspired by this use case I decided to take a stab at creating such an example myself.
  • How to Create a Look and Feel Theme
  • United Desktop Theme for KDE Plasma 5.9
  • KDE Talks at FOSDEM
    The continuation of the original talk from Dirk Hohndel and Linus Torvalds about the port of Subsurface from Gtk to Qt, now with mobile in mind.

SteamVR for Linux, Benchmarks of HITMAN on NVIDIA

  • SteamVR for Linux is now officially in Beta
    Valve have put up SteamVR for Linux officially in Beta form and they are keen to stress that this is a development release. You will need to run the latest Steam Beta Client for it to work at all, so be sure to opt-in if you want to play around with it.
  • Valve Publishes A SteamVR Developer Build For Linux
    Valve has begun rolling out their SteamVR Linux support by announcing today a beta/developer build of their VR support for Linux. Valve's SteamVR for Linux page was updated today to reflect the build becoming public via the Steam beta channel, "This is a development release. It is intended to allow developers to start creating SteamVR content for Linux platforms. Limited hardware support is provided, and pre-release drivers are required. Linux support is currently only available in the "beta" branch, make sure you are using SteamVR[beta] before reporting issues."
  • HITMAN Linux Benchmarks On 12 NVIDIA GPUs
    Last week Feral Interactive released the much anticipated port of HITMAN for Linux. While at first it didn't look like this Linux game port would work out for our benchmarking requirements, thanks to Feral it does indeed work for another interesting Linux gaming test perspective. For our initial HITMAN Linux benchmarks are tests from 12 NVIDIA GeForce GPUs while our Radeon tests will come tomorrow.