redeclipse: packaging symlinks and directory ownership

[Martin Erik Werner]

On Mon, 2012-05-28 at 16:00 -0700, Toshio Kuratomi wrote:
> 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

Ok, I've unpushed it, moved the symlink and repushed, thanks for the
help :)
(Now I just need to find testers :/)

-- 
Martin Erik Werner <martinerikwerner at gmail.com>