On 2/23/06, Philip Ganchev <[EMAIL PROTECTED]> wrote: > 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?
It is kind of hard to decide what is configuration and what is data. The things that have been moved are the command specific completions and a host of shelscript functions. From my point of view, these things are not configuration options, they are a core part of fish, and the files should never actually be edited by the user or sysadmin. If the user wants to change the completions, s/he should create a new completion file to override the old one, and put it earlier in the completion search path. That way the edited completion will get loaded after the next fish upgrade as well. Things like setting the prompt command, IFS, etc.. still live in /etc. > > > 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. Yes it is. The only concern I have here is that it is rather common when updating to a new version of a program to simply do a './configure; make; make install', in which case old files will be left in the filesystem, and in some cases they will override new, better versions of the same functionality, leading the bugs. If the user does a 'make install' s/he is probably aware that the old versions of the fish files will be toasted, but might not have though about dangling files that cause chaos and mayhem.. > > > 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. Isn't that the same thing as (1)? Rename the files so they won't get autoloaded. -- Axel ------------------------------------------------------- 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
