Hello, Le 07/03/2010 20:42, Ville Skyttä a écrit : >> If I change the path in conf.d/BackupPC.conf ; users who have modified >> the .conf file will get a conf.rpmnew file ; that's fine. >> > If apache.users moves from /usr/share/BackupPC to /etc/BackupPC, it'll break > these setups because the old conf.d/BackupPC.conf that is left in place still > refers to the old location, no? > You are right, indeed. > >> The ones who did not change the .conf file will have it replaced by RPM, >> breaking the apache authentication. >> > ...assuming apache.users was modified and the modified one is required for > authentication to work? Is apache.users a config file? If it was not > modified, nothing should break. But I'm guessing that it is a config file and > people are supposed to modify it so it's likely that these setups would break > as well. > apache.users is not shipped by the package, it's up to the user to create it with the appropriate command, and in the right place. By default, .conf and README files are pointing to /usr/share/BackupPC. > >> Any thoughts about that? >> > Not suitable as an update to released distro versions IMO. The way I've > handled cases like this sometime is to do it only between distro versions, and > try to do migration in package scriptlets for some conceivably common cases. > And adding a note about this to distro release notes would not hurt. > > One example of such migration (that I'm not at all proud of, but AFAIK it > ended up working fine) is %post in the vdr package. Hm, I see I've put a TODO > comment to get rid of it in F-13 but have happily forgotten it... will do for > F-14 right away ;) > I think this could be the better solution for that case. A simple symlink as James has proposed would not be ok I think, since the apache.user file is not shipped with the package, It will add a possibly dangling symlink, I'd prefer not to do that. I think I'll do that "the vdr way", it appears to be the most flexible solution for my issue. Many thanks all for your help :-) Regards, Johan -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
