Red Hat Bugzilla – Bug 431726
freeciv and kdegames are fighting for /etc/ggz.modules
Last modified: 2008-02-08 14:41:34 EST
+++ 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
both packages provide the file and it seems to be a config file of sorts.
On first glance, looks like this should be owned by ggz-client-libs as
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 <firstname.lastname@example.org> 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:
ggz-config --install --modfile=...
if [ $1 -eq 0 ]; then
ggz-config --remove --modfile=...
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:
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
[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
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
Just checked in a fix to freeciv (but not built, I'll leave that to bpepple).
Should be good to go now.