sassoftware / conary

Distributed software repository, build, and system management tool
Apache License 2.0
46 stars 10 forks source link

RFE: Publish docs somewhere in HTML format #2

Open ncoghlan opened 9 years ago

ncoghlan commented 9 years ago

The Conary docs are currently appear to only be available as the fodt file in the GitHub repo, which means they don't show up in web searches for information on Conary, and browsers can't readily display them.

It would potentially be useful to export them as HTML and publish them online (e.g. via GitHub Pages)

mikjo commented 9 years ago

The fodt file is only an introduction to the concepts, but that's an excellent idea.

Some of the historical Conary documentation from when rPath maintained it is available in the wiki snapshot at https://opensource.sas.com/conarywiki/index.php/Main_Page

ncoghlan commented 9 years ago

A high level introduction to "How is Conary different from other packaging systems?" is actually one of the key things I'm after :)

For context, I'm a member of Fedora's Environments & Stacks working group, and I'm aiming to tackle the "developer focused packaging" problem.

Conary was recently pointed out to me as a third option worth considering for that task, alongside Nix and Conda: https://fedoraproject.org/wiki/Env_and_Stacks/Projects/UserLevelPackageManagement#Recommending_language_independent_tooling_.28longer_term.29

That means I'm in research mode trying to learn more about Conary's design and capabilities, but Google wasn't being very forthcoming - the clone of the old wiki didn't appear in the search results.

ncoghlan commented 9 years ago

Thanks for that pointer to the old wiki context, it's exactly what I was after! Have you ever explored using MediaWiki's export options on those pages, and then using a utility like http://pandoc.org/index.html to convert them to a source controlled docs format like AsciiDoc?

mikjo commented 9 years ago

First, we'd be delighted if Conary could make RPM packaging easier. It's been on my own personal wishlist for years; just lacked time. SAS chose Apache 2 license because it makes it easy to integrate and use in many contexts, and chose the Linux kernel-style Developer Certificate of Origin for attesting to contributions.

Second, that introductory document assumes Conary as an integrated system responsible for managing the system and providing the repository as well as controlling the build process. Much of the Conary build automation could apply outside of that, and we would accept changes to make it work better as an isolated build technology when it isn't managing system and repository. We demonstrated that Conary groups are just too heavy-weight to represent all of Fedora when we tried to import all of F20 to be a basis for Foresight; at least, as currently implemented. It might be interesting for some of the stacks to use Conary groups to build images from a smaller subset of packages; all of RHEL/CentOS is a reasonable size for Conary groups as they currently stand, and that's our current use case. As you look through the introductory documentation, please consider build automation and image management separately, even though the documentation talks about them as a system.

Hopefully the link in this discussion makes the wiki more visible in google results for now... We had indeed been talking about moving documentation into source-code-managed documentation. Thanks for the pandoc suggestion for implementing such a move.

mikjo commented 9 years ago

Using Fedora 22 LibreOffice, the LibreOffice HTML export from the fodt leaves something to be desired. For example, the embedded image doesn't show up in a browser. PDF is better than not posting HTML version; it might be indexed for web searches. So I'll start by adding that: https://github.com/sassoftware/conary/blob/master/doc/ConaryTechnology.pdf

mikjo commented 9 years ago

If you want to try it out hands-on, starting out with Conary is easier with a bootstrap. That would give an easier way to try out the packaging process, to see whether you find it attractive, with the understanding that the experience of integrating it into the Fedora build process would involve integration with mock etc rather than duplicating the end-to-end experience of the full Conary environment. You asked this question at an opportune time, because we've been working for a few months on a complete open-source release of rBuilder, which took some detangling; and today we finally got all the pieces in place to announce it.

Documentation and download link for installing an rBuilder VM and using it to get started are at http://sassoftware.github.io/appengine/ and we have a new discussion group at https://groups.google.com/forum/#!forum/rbuilder for discussing it.

mikjo commented 9 years ago

Started making Conary docs available via github pages at http://sassoftware.github.io/conary/index.html

ncoghlan commented 9 years ago

Thanks for that! I pointed some of the other Fedora folks at these links and this issue in https://lists.fedoraproject.org/pipermail/env-and-stacks/2015-July/000844.html