[gentoo-dev] Package configuration

[gentoo-dev] Package configuration

[Geert Bevin]

Hello,

I've been playing a bit with portage and try to create a stable and easy
to use postgres package. Doing this I noticed something missing in
portage (maybe I'm just overlooking it, and then all what follows is
obsolete ;-) ).

Typically a package has a configuration phase which occurs after merging
it into the system. This configuration is optional, but could be done
both for binary as source packages. For postgres this is for example the
initialization and installation of an empty database instance. Rocklinux
solves this in a very simple and easy to use manner. It contains an
/etc/setup.d/ directory with simple shell scripts prepended by numbers
in their names (eg. 00-general, 10-gpm, 20-network, 50-sshd, 70-pgsql,
...) It uses these numbers to execute all configs sequentially when a
binary clean install is done from cd. This makes the initial
configuration process modular and very manageable.

When installing a package, emerge could monitor /etc/setup.d/ in a
similar way as it monitors /etc and report whether a new config file is
present and that it can be executed to configure the package that just
was merged.

I hope I explained clearly enough. Tell me what you think of it.

Best regards,

-- 
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

Re: [gentoo-dev] Package configuration

[Mikael Hallendal]

[-- Attachment #1: Type: text/plain, Size: 530 bytes --]

mån 2001-11-19 klockan 11.42 skrev Geert Bevin:
> Hello,

Hi!

> I hope I explained clearly enough. Tell me what you think of it.

If I got you right this issue has been up before. I think the way it
works (once again if I got it right) in Rock Linux is good. Just store
setup-information of all merged packages and let the user setup the
packages once all packages are merged.

Regards,
  Mikael Hallendal

-- 

Mikael Hallendal
Gentoo Linux Developer, Desktop Team Leader
CodeFactory AB, Stockholm, Sweden


[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [gentoo-dev] Package configuration

[Chris Houser]

Geert Bevin wrote:                    [Mon Nov 19 2001,  5:42:34AM EST]         
> Typically a package has a configuration phase which occurs after merging
> it into the system. This configuration is optional, but could be done
> both for binary as source packages.

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.

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.

--Chouser

Re: [gentoo-dev] Package configuration

[Geert Bevin]

> 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

Re: [gentoo-dev] Package configuration

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 2081 bytes --]

On Mon, 2001-11-19 at 17:50, Geert Bevin wrote:
> > 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.
> 

What about the setup script (or pkg_postinst() ) checking if the default
database exist before creating it ?

> > 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
> 
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev
-- 

Martin Schlemmer
Gentoo Linux Developer, Desktop Team Developer
Cape Town, South Africa


[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [gentoo-dev] Package configuration

[Geert Bevin]

Ok, apparently portage already contains what I suggested, but embedded
in the package as the pkg_config() function which is executed with
"ebuild package.ebuild config". Exactly what I wanted :-))

On Mon, 2001-11-19 at 19:26, Martin Schlemmer wrote:
> What about the setup script (or pkg_postinst() ) checking if the default
> database exist before creating it ?

-- 
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

Re: [gentoo-dev] Package configuration

[Daniel Robbins]

On Mon, Nov 19, 2001 at 11:42:34AM +0100, Geert Bevin wrote:
> Hello,
> 
> I've been playing a bit with portage and try to create a stable and easy
> to use postgres package. Doing this I noticed something missing in
> portage (maybe I'm just overlooking it, and then all what follows is
> obsolete ;-) ).
> 
> Typically a package has a configuration phase which occurs after merging
> it into the system. This configuration is optional, but could be done
> both for binary as source packages. For postgres this is for example the
> initialization and installation of an empty database instance. Rocklinux
> solves this in a very simple and easy to use manner. It contains an
> /etc/setup.d/ directory with simple shell scripts prepended by numbers
> in their names (eg. 00-general, 10-gpm, 20-network, 50-sshd, 70-pgsql,
> ...) It uses these numbers to execute all configs sequentially when a
> binary clean install is done from cd. This makes the initial
> configuration process modular and very manageable.
> 
> When installing a package, emerge could monitor /etc/setup.d/ in a
> similar way as it monitors /etc and report whether a new config file is
> present and that it can be executed to configure the package that just
> was merged.
> 
> I hope I explained clearly enough. Tell me what you think of it.

First, I realize that I'm over 40 days late in responding to this email. :)
Sorry about that; I'm finally cleaning out my inbox and catching up on email
that I haven't read yet.

Yes, I think that this could be a really nice arrangement.  But rather than
manually assign a number, I think it would be great if emerge were to auto-
assign the number.  This is how I see it working.  When emerge installs a
package, that package may have installation notes or additional configuration
steps.  So, a package could provide a "setup" file which emerge records in
/etc/setup.d.  Then, when the emerge is complete, emerge would print something
like this:

Additional setup required!  Type emerge --setup to continue.

At which point, the setup scripts could be executed sequentially.  This would
allow for interactive setup of various tools 'n stuff as well.  Since the
setup scripts aren't executed directly in the emerge, they can be interactive.

Best Regards,

-- 
Daniel Robbins                                  <drobbins@gentoo.org>
Chief Architect/President                       http://www.gentoo.org 
Gentoo Technologies, Inc.