"Corey Crawford" <[EMAIL PROTECTED]> writes: > 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. This seems like a matter of having (more general) package-specific configuration files, which currently is not supported. I would imagine though that if such files were supported, it would make more sense for these files to go in a sub-directory of /etc rather than in the portage tree, since either they would be overwritten or they would have to be excluded from rsync, which would cause problems if the package were moved or removed. -- Jeremy Maitin-Shepard -- [EMAIL PROTECTED] mailing list
