Bug 431726 - freeciv and kdegames are fighting for /etc/ggz.modules
freeciv and kdegames are fighting for /etc/ggz.modules
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: ggz-client-libs (Show other bugs)
rawhide
All Linux
high Severity low
: ---
: ---
Assigned To: Rex Dieter
Fedora Extras Quality Assurance
:
: 431725 (view as bug list)
Depends On: 431725
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-06 12:48 EST by Dennis Gilmore
Modified: 2008-02-08 14:41 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-08 14:41:34 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dennis Gilmore 2008-02-06 12:48:59 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
kdegames-4.0.1-1.fc9.x86_64


both packages provide the file and it seems to be a config file of sorts.
Comment 1 Rex Dieter 2008-02-06 12:56:57 EST
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... 
Comment 2 Rex Dieter 2008-02-06 12:57:39 EST
*** Bug 431725 has been marked as a duplicate of this bug. ***
Comment 3 Kevin Kofler 2008-02-06 13:32:25 EST
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.
Comment 4 Rex Dieter 2008-02-06 13:40:51 EST
fyi, ggz-client-libs changelog:
* Wed Feb 06 2008 Rex Dieter <rdieter@fedoraproject.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:

%post
ggz-config --install --modfile=...

%preun
if [ $1 -eq 0 ]; then
ggz-config --remove --modfile=...
endif
Comment 5 Rex Dieter 2008-02-06 13:41:36 EST
Kevin, you're right, of course, I'll need to chat with ggz upstream about that...
Comment 6 Rex Dieter 2008-02-06 13:43:56 EST
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.
Comment 7 Rex Dieter 2008-02-06 14:59:21 EST
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.

----------------------
Comment 8 Kevin Kofler 2008-02-06 15:15:41 EST
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.
Comment 9 Kevin Kofler 2008-02-06 15:28:18 EST
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!
Comment 10 Rex Dieter 2008-02-08 14:41:34 EST
Just checked in a fix to freeciv (but not built, I'll leave that to bpepple).

Should be good to go now.

Note You need to log in before you can comment on or make changes to this bug.