redeclipse: packaging symlinks and directory ownership

[Toshio Kuratomi]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120528/48e601e3/attachment.sig>