| 1 |
On 4/27/06, Kevin <lists@×××××××××.com> wrote: |
| 2 |
|
| 3 |
> If I explore this idea with any further discussion, I'll be sure to |
| 4 |
> follow the suggestions here about another list and reading past messages |
| 5 |
> on that list. |
| 6 |
|
| 7 |
Feel free to look at http://dev.gentoo.org/~radek/portki/ |
| 8 |
|
| 9 |
Short feature lists: |
| 10 |
* designed to run in fully automated way |
| 11 |
* uses master/slave portage replication mode with separate _own_ |
| 12 |
master portage repo |
| 13 |
* additional own repos for home made software |
| 14 |
* allows different upgrade cycles per machine (weekly/monthly/yearly, glsa only) |
| 15 |
* allows automatic cfg upgrade _if_ file was not touched by human. |
| 16 |
* does all necessary cleaning |
| 17 |
* extensive logging |
| 18 |
* does revdep-rebuild and other necessary portage tricks |
| 19 |
* allows central configuration (useflags, make.conf etc.) |
| 20 |
* it used binpkg in early version but I discarded this idea because of: |
| 21 |
.. problems generated even on compatibile hosts |
| 22 |
.. necessity to have all the same cfg (which is often not the case) |
| 23 |
.. small gain (on todays servers compilation is fast) |
| 24 |
.. much harder individual changes to the machines |
| 25 |
* its just an integration work (mostly bash and python) around |
| 26 |
standard gentoo tools, although its in highly automated state. |
| 27 |
* easy to extend |
| 28 |
|
| 29 |
Biggest drawbacks: |
| 30 |
* some bugs :) |
| 31 |
* lacking documentation |
| 32 |
|
| 33 |
-- |
| 34 |
radoslaw. |
| 35 |
|
| 36 |
-- |
| 37 |
gentoo-dev@g.o mailing list |
Archives