| 1 |
> Usually, portage addresses this by providing good defaults and then |
| 2 |
> documentation for less standard configuration. If you need something to |
| 3 |
> be executed (non-optionally) after merge, you can define a |
| 4 |
> pkg_postinst() function in your ebuild. I think this addresses a large |
| 5 |
> percentage of the cases without adding a more complex mechanism. |
| 6 |
|
| 7 |
Problem is this example situation. I install postgres which creates the |
| 8 |
default database by default. Then one day I want to upgrade and again a |
| 9 |
default database is created and it overwrites the existing one .... |
| 10 |
major catastrophy ! Having a setup script available and notifying the |
| 11 |
user of its existance makes it easy to install a default setup without |
| 12 |
having to wade through the manuals of all the software before being able |
| 13 |
to use it and protects an unwary user from accidentally erasing or |
| 14 |
overwriting existing data files. |
| 15 |
|
| 16 |
> Some sort of post-install user interaction has been discussed, with |
| 17 |
> everything from an interactive config GUI to listing recommended |
| 18 |
> documentation. This may be written eventually, but the set of possible |
| 19 |
> solutions is large, diverse, and heavily dependant on personal taste, |
| 20 |
> all of which tend to slow down the actual writing of code. |
| 21 |
|
| 22 |
Imho, starting with basic bash scripts is a good approach. When text ui |
| 23 |
and gui become available additional support for those can be added |
| 24 |
later. |
| 25 |
|
| 26 |
|
| 27 |
-- |
| 28 |
Geert Bevin |
| 29 |
the Leaf sprl/bvba |
| 30 |
"Use what you need" Pierre Theunisstraat 1/47 |
| 31 |
http://www.theleaf.be 1030 Brussels |
| 32 |
gbevin@×××××××.be Tel & Fax +32 2 241 19 98 |
Archives