Ralf S. Engelschall wrote:
What is the reason for moving the generation of the db.debot file from %post into %start? Has the "sleep 1" something to do with it? Also, is is security-wise reasonable or required to set "super user" to the OpenPKG super-user (which usually is "root")?
In my case, I wanted the ability to install the perforce package for client usage, server usage, or both. For the common use case at my site (client-only), it seemed bad to create a perforce depot at all, or even start the daemon (however briefly). I suspect that client-only usage is probably much more common "in the field", as well.
I decided to guard the depot creation by adding the "perforce_daemon" option (ala cvs_daemon), and then check that it was enabled before creating the depot. A consequence of having the ability to toggle perforce_daemon on or off is that checking for depot creation once upon first install is no longer sufficient -- it must be done each time the user attempts to start the perforce daemon. This is what necessitated the move of the depot creation code to rc.perforce.
To be honest, I am not completely happy with the idea of auto-creating the depot at all. I preserved this behavior old version of the package because I assumed that the creator of that package felt it was important. I attempted to preserve the original intent of the package, while making it much friendlier to the common client-only use case.
Sadly, I'm afraid that I don't know much about the perforce "protect" command, or how server-side permissions work, so I can't immediately answer your question about "super user". If you think depot creation is something the package should continue to do, I can research this a bit more. If you think depot creation should disappear, the permission issue becomes a moot point.
-- Larry Lansing ______________________________________________________________________ The OpenPKG Project www.openpkg.org User Communication List openpkg-users@openpkg.org
