redeclipse: packaging symlinks and directory ownership

[Martin Erik Werner]

On Mon, 2012-05-28 at 19:31 +0200, Martin Erik Werner wrote:
> Hello,
> I have a couple of packaging questions for a new package, the FPS game
> redeclipse[0], which are currently in testing[1].
> 
> 1.
> I have three resulting binary packages {redeclipse, redeclipse-server,
> redeclipse-data} where redeclipse depends on redeclipse-data as the only
> inter-dependency. (Splitting -data into a separate source package is a
> future todo item...)
> 
> Currently all packages place files in %{_libexecdir}/%{name}/ (client
> binary, server binary, and a symlink to the data dir).
> 
> In this case, should only the -server and -data packages own this
> directory, or would it be more appropriate if all three owned it?
> 
> 2.
> I was thinking of moving the symlink from the -data package to the
> client ("redeclipse") package, which would mean that unless the -data
> dependency is installed, there would be a broken symlink, is this
> something that's acceptable? Or need symlinks be unbroken within a
> single package regardless of dependencies?
> 
> 3.
> redeclipse is currently pushed as an update to testing[1] (not in stable
> yet), and this version includes the unowned directory
> %{_libexecdir}/%{name}/ (which I discovered recently).
> 
> What would be my course of action with regards to the f17 update? Should
> I abort it and push a new one (and go through the review process?), or
> should I let it go and fix this in a subsequent update; how critical are
> unowned dirs like this?
> 
> 
> Thanks.

[0] https://bugzilla.redhat.com/show_bug.cgi?id=800930
[1] https://admin.fedoraproject.org/updates/redeclipse-1.2-9.fc17

Whoops forgot those :)

-- 
Martin Erik Werner <martinerikwerner at gmail.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120528/9998fd0d/attachment.sig>