On Mon, May 28, 2012 at 11:25:43PM +0200, Martin Erik Werner wrote:
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?
>
I would lean towards only the -server and -data package owning this due to
the client depending on -data.
> 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?
>
As long as the dependency from -client to -data exist, this should be fine.
> 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?
>
I'd abort, build a fixed version, and push that. there's no need
for
a re-review for that. For the end user it shouldn't have much effect.
For how serious, here's the Packaging Guideline page that explains the
various issues it can cause:
http://fedoraproject.org/wiki/Packaging:UnownedDirectories
-Toshio