[Slackbuilds-users] [sbopkg-users] Sbopkg 0.27.2 Released
rw at rlworkman.net
Thu Apr 30 18:18:16 UTC 2009
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:
> 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
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. :-)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: not available
More information about the SlackBuilds-users