+++ This bug was initially created as a clone of Bug #431725 +++ Description of problem: trying to update im getting Transaction Check Error: file /etc/ggz.modules from install of freeciv-2.1.3-2.fc9.x86_64 conflicts with file from package kdegames-4.0.1-1.fc9.x86_64 both packages provide the file and it seems to be a config file of sorts.
Brian, On first glance, looks like this should be owned by ggz-client-libs as (something like): %config(noreplace) /etc/ggz.modules and managed by consuming pkgs via %post/%postun scriptlets using ggz-config. I'll see about finding out more details...
*** Bug 431725 has been marked as a duplicate of this bug. ***
The best solution in such a situation would be an /etc/ggz.modules.d where all the modules can drop in their files. It may require patching ggz though.
fyi, ggz-client-libs changelog: * Wed Feb 06 2008 Rex Dieter <rdieter> 0.0.14-5 - %config(noreplace) %_sysconfdir/ggz.modules (#431726) - own %_datadir/ggz, %_libdir/ggz Looks like pkgs will need to use scriptlets to register using something like: %post ggz-config --install --modfile=... %preun if [ $1 -eq 0 ]; then ggz-config --remove --modfile=... endif
Kevin, you're right, of course, I'll need to chat with ggz upstream about that...
fwiw, module description files are supposed to be dropped into /usr/share/ggz/*.dsc , maybe we can prod upstream to parse those at runtime without the need to "register" items into /etc/ggz.modules. dunno.
Here's my first quick-n-dirty draft of something that may eventually evolve into a packaging guideline about this stuff: http://fedoraproject.org/wiki/PackagingDrafts/GGZ :) After chatting with ggz upstream, looks like we'll likely have to live within the current ggz way of doing things for the foreseeable future... ---- #ggz excerpt ---- [13:27] <rdieter> I've got a couple questions about ggz packaging, and handling module registration (/etc/ggz.modules). [13:28] <rdieter> my understanding is that ggz-client-libs-using apps are supposed to register themselves via: ggz-config --install --modfile=... [13:28] <rdieter> and on uninstall, presumably, a like-wise, ggz-config --remove --modfile=... [13:28] <rdieter> right so far? [13:30] <rdieter> this is pretty inconvenient for distro packaging. A better solution from my POV (as packager) would be for this registration to be performed at runtime (parse *.dsc files at runtime or whatever). [13:31] <rdieter> am I crazy? dreaming? [13:36] <josef|samba> that'd be doable, but then it might get messy in the case of conflicts (which ggz-config is supposed to detect) [13:37] <josef|samba> it's not very inconvenient havin a one-liner per package and per postinst or preinst hook [13:40] <rdieter> ok. [13:43] <josef|samba> some time ago I've thought about the issue a bit - we could have something like $GGZ_DATA_DIRS pointing to whereever apps copy these files, and then let ggz-config operate on them individually somehow [13:44] <josef|samba> but I'm not sure what the implications would be [13:44] <josef|samba> on the other hand I'm totally sure I won't be able to try this out somewhen soon [13:44] <rdieter> :) [13:44] <rdieter> well think about it, even what your suggesting would be an improvement. ----------------------
Yuck, this sounds like one of those cases where our goals and upstream's clearly diverge. It is totally unacceptable to "detect conflicts" in a scriptlet, as a scriptlet is not allowed to fail.
That said, I looked at the structure of the code and adding support for a config directory would require either API incompatibility with upstream (for the API between ggz-client-libs and libggz) or some horrible kludge. In fact, ggz-client-libs lets libggz handle all the actual config file parsing, but that code is designed entirely on the assumption that configuration is read from a single file, as it works with file handles. So I think patching this wouldn't be worth it. We definitely need to make sure those scriptlets don't fail though! Ever!
Just checked in a fix to freeciv (but not built, I'll leave that to bpepple). Should be good to go now.