<vericgar> I think I just found an issue with clean upgrade paths after we merge on Saturday... module configuration files. For most modules, the config file the ebuild references is the same before and after the merge, but the config file changes after the merge (due to path changes extramodules -> modules). The issue is that if someone installs a module after our merge, but before the merged ebuilds are in stable, they will get the old ebuild with the new config, and the new config won't work (because paths haven't changed) <vericgar> the hackish solution is to rename the config file for the new ebuild, for example files/11_mod_auth_kerb.conf would become files/12_mod_auth_kerb.conf (or whatever you want), but it can't contain the version/revision of the ebuild because filenames are kept when installing config files in the eclass. (This is an issue because of CONFIG_PROTECT, the installed config files for the same module but different versions would be different) <vericgar> The optimal solution would be a change to the eclass that allows the ebuild to specify the filename of the config, and what it should be installed as (currently it only accepts the filename of the config in the files/ directory and uses the same filename when placing it in /etc) <vericgar> both ways will require changing every module. The third solution (not really) is to just leave it, and tell users who file bugs to fix the paths in the config or upgrade to the unstable version
<Stuart> vericgar: just put the config files into a directory under ${FILESDIR}, like we used to do for apache itself <vericgar> Stuart: hmm. that will work. still need to change all the to-be-merged ebuilds, but that's not a big deal.
I believe I have fixed all cases where the configuration files would overwrite the ones currently in portage. I will double-check every package as I do pre-merge QA.
Verified that all packages were fixed before the merge.
