[Slackbuilds-users] [sbopkg-users] Sbopkg 0.27.2 Released

[Robby Workman]

On Thu, 30 Apr 2009 14:03:13 -0400
Chess Griffin <chess at chessgriffin.com> wrote:

> * Robby Workman <rw at rlworkman.net> [2009-04-30 12:32:27]:
> 
> > On Thu, 30 Apr 2009 11:44:31 -0400
> > Chess Griffin <chess at chessgriffin.com> wrote:
> > 
> > > Be sure to migrate the changes from sbopkg-renames.new to your
> > > sbopkg-renames (or just rename the file) in order to pick up the
> > > two more renamed packages.
> > 
> > 
> > What's the rationale for a this being an admin-editable file?  To
> > clarify, what's the potential use case for it being necessary?
> 
> The original idea was to have an easy way to take care of renamed
> files without necessarily having to update sbopkg itself.  If there
> is a lag between a renamed file and an sbopkg release, the admin can
> edit the file himself.


Okay, that's fair.  Keep reading though... :-)


> Additionally, there is the potential that someone might want to make
> use of the 'local' repo feature in sbopkg, and have a 'local' version
> of an app that, through the renames file, can override something in
> the official SBo repo, e.g. in sbopkg-renames:
> 
> mplayer=my_custom_mplayer_with_leet_config_options
> 
> In this case, if the admin 'updates' his local leet mplayer script,
> then it will appear as an update in sbopkg.


Right; keep reading...  :-)


> > If it is necessary for the local admin to have a 'renames' file or
> > some such, then I'd suggest having sbopkg look for an
> > "sbopkg-renames.local" file for that -- I don't think it's a good
> > idea to potentially allow the renames file to be out of sync (which
> > the .new allows).
> > 
> 
> Still, I can understand the overall concern that the renames file
> could be out of sync.  Maybe, as you suggest, having both an
> sbopkg-renames and an sbopkg-renames.local where the admin can add
> personalized changes is the way to go here.  The sbopkg-renames is
> overwritten each time sbopkg is updated, thus ensuring the new
> additions are picked up without wiping out anything in
> sbopkg-renames.local.


That the admin might want to get a "head start" on a renamed package
before sbopkg has an updated version is a non-issue; he could do that
regardless, and then the clobbering of the file on the next update
wouldn't change anything, while the benefit is exactly as you surmised
-- there's no danger of having an out-of-sync primary list of renames.

A local renames file (or even a renames.d/ directory) should handle the
remainder of the valid cases just fine, I think.  The benefits of the
renames.d/ directory would be similar to the /etc/modprobe.d/ directory
-- it would allow for easier maintenance of local rename lists.

All that said, I certainly wouldn't change this in the stable branch,
and even in svn, my standard disclaimer applies: it's YOUR code.  :-)

-RW
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20090430/f39b40d1/attachment.asc>