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

[Chess Griffin]

* 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.

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.

> 
> 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.

-- 
Chess Griffin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20090430/06e89af5/attachment.sig>