prun: Add documentation in markdown format #201
Conversation
Manual pages can be generated with: pandoc --standalone --to man prun.md -o prun.man.1
|
Installation needs to be checked, since pandoc comes from a package. |
|
Wow. Documentation! Very unusual, very good. |
prun/prun.md
Outdated
| AUTHORS | ||
| ======= | ||
|
|
||
| D.Buczek, P.Marquardt, M.Tolzmann |
There was a problem hiding this comment.
No, I managed to do the 10 lines on my own. But I don't want to boast about it. Okay to leave out the credits section.
A "build" step ("make && make install") does not work here unless the compilation output is stable (identical on each build). If there was, for example, a comment with a timetag in the output, this would be a problem. mxtools doesn't have a global version number, so "make install" installs whatever is different from the installed version. Each "make install" of two people with the same checked out sources would install the semantically equal but binary different output files over each other every time. We had that with a binary output and removed the program from mxtools for that reason ( #135 ). Another reason was that at that time the files installed by mxtools were not visible to If the pandoc output is stable, I think we should just add a "make" phase to build the man pages. Why is it important that we have pandoc in a package? Its just a command, isn't it? To check in the pandoc output... Well thats ugly. But if we don't have a better idea, we might do that. |
prun/prun.md
Outdated
|
|
||
| The main usage is to run software in a specific version, or to provide a given environment. See **EXAMPLES** below. | ||
|
|
||
| There are some advantages over so called 'virtual environments' and the like. Packages are immutable, once installed they never change, thereby increasing the chances that an old program/script will also run in a few years. The packages also |
|
pandoc output seems to be stable. I've suggested build logic in #202. |
|
Prun is a little bit like the tip of the iceberg of the whole package
machinery. My thought was to mention the main devs in this place.
|
|
My main concern is about calling an 'alien' binary as root.
|
|
We could make |
|
This sounds reasonable :)
|
Okay, I'm not aware of Peters and Marius' part, but I don't really care anyway. Leave it as it is. Sorry for bringing this up. |
Use `-f` flag of `rm` to avoid error messages from `make clean` when the targets files don't exist.
|
I've added something to that "don't do that as root" effect to #202. |
|
'Authors'
Maybe I had a wrong picture from the past, where the whole thing started
to evolve. I can also dump the Authors, no cause of worries.
|
|
Yepp, now I can sleep well again ;)
|
| DESCRIPTION | ||
| =========== | ||
|
|
||
| Similar to **type** or **which**. **ptype** gives information about a package binary. **type** would only tell something about the package wrapper, and not about the package where the real program is. |
|
#202 is a PR to merge into this branch. So i think you can just press "merge" (and then "pulL" this branch into you local repository) if you want to include it. |
|
Will check it tomorrow, right now my browser is way old...
It says: `User agent: Mozilla/5.0 (X11; Linux i686; rv:43.0)`
|
prun/pman.md
Outdated
| DESCRIPTION | ||
| =========== | ||
|
|
||
| **ptype** uses the PATH set in the package wrapper and tries to find a manual page in the package directory. |
There was a problem hiding this comment.
Do you mean pman here instead of ptype?
Add build/install logic for prun manpages
Remove authors from prun.md, reformat Remove copy-and-paste errors in pman.md
|
|
Manual pages can be generated with:
pandoc --standalone --to man prun.md -o prun.man.1