Talk:Conary (package manager)

From Wikipedia, the free encyclopedia

This article is part of WikiProject Free Software, an effort to create, expand, organize, and improve free software-related articles.
Stub rated as stub-Class on the assessment scale
Low rated as low-importance on the assessment scale
This article is part of the Linux WikiProject, a group of Wikipedians interested in improving the encyclopaedic coverage of articles relating to Linux, and who are involved in developing and proposing standards for their content, presentation and other aspects.
If you would like to participate, please visit the project page, where you can join the project and see a list of open tasks.
Stub This article has been rated as Stub-Class on the quality scale.
This article has been automatically rated as Stub-Class because it uses a stub template.
  • If you agree with the assessment, please remove |auto=yes from this template.
  • If you disagree with the assessment, please change it by editing the class parameter in this template and removing |auto=yes from the template and also remove the stub template from the article.

[edit] What is the licence?

I searched the website but didn't find much. I found some references to the MIT license, but I don't know whether that covers Conary or some external parts. Articles about free software should provide a link to the licence in the External links section. Gronky 20:55, 28 August 2006 (UTC)

It appears to be CPL. Source is here: [1].
Confirmed, thanks. Gronky 09:11, 26 June 2007 (UTC)

[edit] rmake

I moved the following paragraph here, since it does not belong in the article.--Chealer 19:15, 19 May 2007 (UTC)

A companion open source tool, rmake, is also provided by rPath. It is a build server for conary packages, which builds packages inside chroot environments containing only the package's explicitly listed build requirements and some other fundamental packages. This is very useful for packagers, because it means that package builds can be done inside a reproducible environment, and packagers cannot accidentally introduce dependencies on peculiarities of their machine's environment (such as custom configuration files, or undocumented extra packages).

Why doesn't it belong in the article? I think it is useful for people comparing different Linux package management systems.—greenrd 23:30, 19 May 2007 (UTC)