On 2/22/06, Axel Liljencrantz <[EMAIL PROTECTED]> wrote: > At the suggestion of Freso and Jamessan, I have remade the fish > directory structure so that archidecture independant data, such as > completion information and shellscript function definitions now live > in $PREFIX/share/fish/, not /etc/fish.d/. This new layout means much > fewer files in /etc, and much fewer changes in those files.
I'd prefer all the config files to be in the same directory, or at least be linked to /etc/, despite the purist ideals of the Unix Filesystem Hierarchy Standard. If Fish's hierarchy must be changed, how about adding links to /etc/ so that users can find the files? > But changing such things always results in potential upgrade glitches. > I'm worried that a lot of the poeplte who upgrade using the source > tarball will skip using 'make uninstall' before installing the new > fish version, hoping that the new files will simply overwrite the old > ones. In this case, it will leave a lot of dangling files in /etc, > files whose functionality is replaced by other files in > $PREFIX/share/fish/. I'm thinking that maybe the fish installation > scripts should try to help the user with this task, but I'm not sure Is this different than the question What to do with existing configuration files in general (i.e. if Fish's directory hierarchy stays the same)? I suggest treating them the same way. > how. Here ara a few options that I see: > > * Automatically rename files with a name that is known to have been > previously used by fish. This seems scary since a sysadmin might > create a /etc/fish.d/fish_functions.fish files and be in for a > surprise. > * Pause the install process to interactively ask the user if s/he want > to rename the relevant files. > * Refuse to install if old deprecated init files still exist, and tell > the user to use 'make uninstall' first. > * Just send a big warning message if the relevant files are already > present, but don't take any action. > > The first one, while helpfull, seems a bit to dangerous. The second > one, while nice, seems like it could jam up automated buildprocesses. > The third one is probably the one I like best, it might be a hassle, > but it should be safe. The fourth one, while not very dangerous, means > that all the people who don't pay attention to the build logs, will > have a less than Of those four I prefer (3) and (4), if I understand correctly. I agree (1) is not desirable. How about 5. Rename the old files to filename.fish_old or filename_date.fi and inform the user. The new filename should not end on .fish, or the init script cannot safely source *.fish. ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 _______________________________________________ Fish-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fish-users
