RE: [gentoo-dev] Ebuilds and the changes people make to them

[Corey Crawford]

> -----Original Message-----
> From: Paul de Vrieze [mailto:pauldv@g.o]
> Sent: Saturday, November 08, 2003 2:19 PM
> To: gentoo-dev@g.o
> Subject: Re: [gentoo-dev] Ebuilds and the changes people make to them
>
> [blunt reply]
> On a production system one should allways read changelogs before
> updating, and possibly even first test it. Also having binary packages to
put back if
> things won't work is very useful.
> [/blunt reply]
>
> > Has anyone considered moving any 'configure' options to another file?
>
> I don't think so. It would also be complicated because sometimes
> configure scripts themselves change defaults or other packages depend on
certain
> configure options being present (which makes it not optional to
> not use the option).
>
> > Moving the 'configure' options to another file would alleviate a lot of
> > problems. This would allow those of us who have working systems to
continue
> > to have functioning systems even if the default values for those
configure
> > options have changed.
>
> I understand your problems, I agree with it, however I see no way
> of solving the problem. The best guarantee for stability is not updating
> unless needed, and in that case be very careful (a diff between the old
ebuild
> and the new one).
>
> Paul
>
> --
> Paul de Vrieze
> Gentoo Developer
> Mail: pauldv@g.o
> Homepage: http://www.devrieze.net

This change was not in the ChangeLog - though I didn't diff the ebuilds
until after I had already emerged it. (Doh!)

I don't see why you couldn't have configure options in a separate file.
Sure, I understand that some configure options are required - but when you
first get the package you should get all those defaults in the separate
file. (It would be included with the ebuilds much like ChangeLog is).

Once you had those defaults you could make changes to them so that following
upgrades will use the same options. The file could actually have the values
for those configure options as variables rather than the whole
'--option=value' string. The ebuild script would then reference those
variables or use defaults if the variable isn't available in the
configuration file.

This would allow us to only specify specific things if we want (such as
paths), but use defaults for everything else.

Since this is a scripting thing, each ebuild could be modified as time went
on and wouldn't require all of them to use this system right away.

Ideally, I'd like to see something like this, using apache as an example..

 [Files]
  Configuration-apache2.defaults
  Configuration-apache2.custom
  Configuration-apache.defaults
  Configuration-apache.custom

 [In Configration-apache2.defaults]
  $DocRootPath = "/var/www/"
  $OtherVariables = ....

 [In Configuration-apache2.custom]
  $DocRootPath = "/home/www"

Since apache has two versions available to emerge, you would need two
different sets of configuration files.

Any variables in .custom would override variables defined in .defaults. If
the ebuild maintainer needs to make changes to the configure options then
he/she simply makes changes to the .defaults file, leaving any overridden
options alone in the .custom file.

Just an idea. Would make my life easier :)

---
Corey Crawford
ccrawford@×××××××.net


--
gentoo-dev@g.o mailing list