redeclipse: packaging symlinks and directory ownership

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
-- 
Martin Erik Werner <martinerikwerner@xxxxxxxxx>

Attachment: signature.asc
Description: This is a digitally signed message part

-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux