From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gbevin@theleaf.be>
X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on finch.gentoo.org
X-Spam-Level: 
X-Spam-Status: No, score=0.3 required=5.0 tests=DMARC_NONE,MAILING_LIST_MULTI,
	RDNS_DYNAMIC autolearn=no autolearn_force=no version=4.0.0
Received: from lark.theleaf.office (cable-213-132-142-63.upc.chello.be [213.132.142.63])
	by chiba.3jane.net (Postfix) with SMTP id 5A5E1EEE1
	for <gentoo-dev@gentoo.org>; Mon, 19 Nov 2001 09:52:38 -0600 (CST)
Received: (qmail 27963 invoked from network); 19 Nov 2001 15:50:23 -0000
Received: from unknown (HELO willow.theleaf.office) (10.1.1.3)
  by 10.1.1.1 with SMTP; 19 Nov 2001 15:50:23 -0000
Subject: Re: [gentoo-dev] Package configuration
From: Geert Bevin <gbevin@theleaf.be>
To: gentoo-dev@gentoo.org
In-Reply-To: <20011119100550.C147024@plato.zk3.dec.com>
References: <20011119100550.C147024@plato.zk3.dec.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Evolution/0.99.0 (Preview Release)
Date: 19 Nov 2001 16:50:46 +0100
Message-Id: <1006185046.339.0.camel@willow>
Mime-Version: 1.0
Sender: gentoo-dev-admin@gentoo.org
Errors-To: gentoo-dev-admin@gentoo.org
X-BeenThere: gentoo-dev@gentoo.org
X-Mailman-Version: 2.0.6
Precedence: bulk
Reply-To: gentoo-dev@gentoo.org
List-Help: <mailto:gentoo-dev-request@gentoo.org?subject=help>
List-Post: <mailto:gentoo-dev@gentoo.org>
List-Subscribe: <http://lists.gentoo.org/mailman/listinfo/gentoo-dev>,
	<mailto:gentoo-dev-request@gentoo.org?subject=subscribe>
List-Id: Developer discussion list <gentoo-dev.gentoo.org>
List-Unsubscribe: <http://lists.gentoo.org/mailman/listinfo/gentoo-dev>,
	<mailto:gentoo-dev-request@gentoo.org?subject=unsubscribe>
List-Archive: <http://lists.gentoo.org/pipermail/gentoo-dev/>
X-Archives-Salt: 6d0c2676-bf41-4619-ab12-141afab8d299
X-Archives-Hash: e4d1b019fb128bc949757f54a711c988

> Usually, portage addresses this by providing good defaults and then
> documentation for less standard configuration.  If you need something to
> be executed (non-optionally) after merge, you can define a
> pkg_postinst() function in your ebuild.  I think this addresses a large
> percentage of the cases without adding a more complex mechanism.

Problem is this example situation. I install postgres which creates the
default database by default. Then one day I want to upgrade and again a
default database is created and it overwrites the existing one ....
major catastrophy ! Having a setup script available and notifying the
user of its existance makes it easy to install a default setup without
having to wade through the manuals of all the software before being able
to use it and protects an unwary user from accidentally erasing or
overwriting existing data files.

> Some sort of post-install user interaction has been discussed, with
> everything from an interactive config GUI to listing recommended
> documentation.  This may be written eventually, but the set of possible
> solutions is large, diverse, and heavily dependant on personal taste,
> all of which tend to slow down the actual writing of code.

Imho, starting with basic bash scripts is a good approach. When text ui
and gui become available additional support for those can be added
later.


-- 
Geert Bevin
the Leaf sprl/bvba
"Use what you need"           Pierre Theunisstraat 1/47
http://www.theleaf.be         1030 Brussels
gbevin@theleaf.be             Tel & Fax +32 2 241 19 98