Buzzwords, marketingspeak, and/or other jargon [LWN.net]

Buzzwords, marketingspeak, and/or other jargon

Posted Jun 10, 2005 14:43 UTC (Fri) by kevinbsmith (guest, #4778)
Parent article: A look at rpath Linux

It is so frustrating to read an "introduction" to a product or project, only to find that it was written for an audience that already knows what the product does and why someone might want to use it. It's sadly common among home pages of FLOSS projects, and conary falls into the same trap. After reading the article, and the linked introduction to conary, I *still* had very little idea what conary might offer over the other packaging systems that I have used: emerge and apt.

If I could offer one word of advice, it would be to include specific examples of real-world situations where existing tools do a poor job, and the new tool helps. The example in the article about abiword and enchant is a step in the right direction, but for those of us who have no idea what enchant is, or why it has 3 components, it just adds to the confusion.

Poking around on the conary wiki, I found this, which was more informative:
http://www.rpath.com/technology/techoverview/

But based on that document, conary seems to mostly solve problems found in the RPM world. As a typical desktop user, it's still not clear to me how conary would be better than emerge or apt.

On a different topic, the description of the long-term goals of rpath sound similar to progeny's componentized Linux. It would be interesting to see a comparison between those two projects.

(Log in to post comments)

Buzzwords, marketingspeak, and/or other jargon

Posted Jun 11, 2005 3:04 UTC (Sat) by msw (subscriber, #3733) [Link]

> But based on that document, conary seems to mostly solve problems found in
> the RPM world. As a typical desktop user, it's still not clear to me how
> conary would be better than emerge or apt.

Enabling people to modify and customize the software components in a Linux based distribution was is of the major design goals for Conary. dpkg, rpm, portage, etc. don't give you the facility to do distributed development of an entire Linux-base distribution.

I was talking to a help desk staffer after my Conary presentation at TruLUG last night. He was asking why we didn't have Conary three years ago when the organization was deploying Red Hat Linux 7.3 to non-technical desktop users. They added StarOffice as the office suite, but integrating it into the distribution was extremely difficult. They wanted to modify the mailcap package so that StarOffice would automatically be used to open .doc files downloaded in Netscape. They ended up creating their own "ourcompany-mailcap" package because there wasn't a way to maintain that local modification to the mailcap package.

With Conary, the company would be able to create a special type of branch of the mailcap package. We call these branches "shadows". They would be able to make their local modifications on that shadow, which could be stored on a local Conary repository. Shadows keep track of the ancestry of the package, which allows you to easily merge in changes that happen "upstream" of the shadow.

Conary brings a paradigm shift in how software is managed on Linux systems, and how Linux distributions are built and customized. It takes a bit of time to see the whole system when you're looking at it from a "how is it better than APT, YUM or Portage" perspective.

Buzzwords, marketingspeak, and/or other jargon

Posted Jun 13, 2005 1:41 UTC (Mon) by hazelsct (guest, #3659) [Link]

I'm sorry, but I too fail to see the advantage, at least over .debs (don't know about RPMs). The mailcap examples can be treated as a simple case of configuration file customization, which dpkg tracks straightforwardly -- and debconf does even better, as it substitutes configuration options correctly even as file formats change, where "shadows" might manage for small changes but will inevitably fail in the general case. (In fact, the http backend of debconf allows one to set site-wide configuration options which are seamlessly integrated into every machine's package-by-package conf files, automagically upgraded, etc.)

Perhaps this is why Debian has been so successful as a base for new distributions...

But again, how is it again that conary does this better than dpkg?