The generic problem at hand is of files (configuration, libraries etc.) that are - Created by Program 1 (in their local directory per gobo structure) and linked globally - Updated by Program 2 (again in their own local directory) and then NOT linked globally (by default but force can do it) ....Forcing the link to the updated file in Program 2 might be one solution - But if Program 1 uses the local file and does not use the global symlink, then the local file in its program directory has to be updated
One solution: - Allow Recipe designer to specify a conflict_<filename>=<value> where <filename> is the filename which is conflicting and <value> is the option to take Keep - keep existing link Force - replace existing link Replace - replace original file pointed to by link (dangerous but clearly needed in these situations) In this example, PROG1 is GTK+, PROG2 is LibRSVG, File in question is gdk-pixbuf.loaders LibRSVG complains about the conflict but leaves the original file as is....this breaks software which need the file EVEN if you force symlink (which an end user would not know) ...then also it does not work You needed to do: gdk-pixbuf-query-loaders > /Programs/GTK+/Setting/gtk2.0/gdk-pixbuf.loaders Now, if the compile script has replaced the original with the file it had generated that would solve it...obviously the recipe writer has to catch this... Jonas Karlsson wrote: > 2007/7/5, Anshuman Aggarwal <[EMAIL PROTECTED]>: > >> Yeah, that's what I had done as a workaround...I think the post install >> script for the LibRSVG should do it...instead of generating a >> conflicting file....or atleast it should instruct the user....but these >> 'global' config files need to be maintained...but I bet that's what the >> dev mailing list has been hot about for the last few weeks :) >> > > There are a way to fix this by adding code to > Compile/InstallPackage/SymlinkProgram to run these functions if some > file exists. Much like I did for update-mime-database. > Another approach is to add an API to the tools to be called from hooks > in Recipes/PostInstall, e.g. Update_MIME_Database(), so the > contributer/packager are responsible for calling the functions, if > needed. > > First is better because it's completly automated, so the contributer > wouldn't have to remember to call the function if needed. But fully > automated *may* be errorprone. > > _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
