> -----Original Message----- > From: Paul de Vrieze [mailto:[EMAIL PROTECTED] > Sent: Saturday, November 08, 2003 2:19 PM > To: [EMAIL PROTECTED] > 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: [EMAIL PROTECTED] > 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 [EMAIL PROTECTED] -- [EMAIL PROTECTED] mailing list
