Axel, Using Gentoo, I have a bit of a different outlook on the changes you are recommending. Gentoo allows you to mask certain directories, like /etc, and whenever an install wants to put a file there, it is "queue" and then I have to manually put it in place, so there is no need for the "make install" process to do that.
This is a great feature of Gentoo. I am not certain how other package managers handle this issue. Sean On Wednesday 22 February 2006 18:06, Axel Liljencrantz 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. > > 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 > 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 > > Opinions are welcome! > > -- > 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 -- Sean Higgins, [EMAIL PROTECTED] http://www.systura.com - "Where information becomes knowledge." ------------------------------------------------------- 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&kid=110944&bid=241720&dat=121642 _______________________________________________ Fish-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fish-users
