Bugs for Sorcery are reported here

[bugzilla-daemon AT bugs.sourcemage.org]

http://bugs.sourcemage.org/show_bug.cgi?id=15093





--- Comment #2 from Donald Johnson <ltdonny AT gmail.com>  2009-02-27 17:56:56 
---
Some spells cannot follow the rules, and while Sorcery is highly functional 
for
packages that work, it is often not functional or expedient for debugging.  
For
one, it doesn't pick up a compile where it left off, which loses that powerful
ability from make, especially for debugging purposes.  Two, sometimes an admin
needs to install a different version of a package that may not work with the
build system that Sorcery uses, and thus is cut out of that by using the
version that can provide certain dependencies.

For a real example, I currently have Virtualbox as a virtual package.  It is
not installing correctly, namely the init scripts are not installed by 
Sorcery.
 Now, I can file a bug report and wait for a new version of the grimoire to
come out so that it will install the init script, or I can virtualize the
package and install it myself after filing such a bug and work around it
quicker.  This can be especially important for security concerns and applying
custom patches to a package.

A case hypothetical would be that I want to just install a binary package that
I myself have taken some pains to compile, such as the combo of gtk+2, pango,
and cairo.  I don't want to take time to necessarily compile those, so I can
throw in a virtualized package for those three and all dependencies could be
solved that way.

Another case hypothetical would be applying a patch to nethack.  There's no 
way
to apply a patch without delving into the hierarchy of
/var/lib/sorcery/codex/... and knowing exactly what to change or how, thus the
best course would be to virtualize the package.  Currently the way now is to
blank or comment out everything in the PRE_BUILD, BUILD, and INSTALL files and
put "/bin/true" (or similar) in it.

One more hypothetical case would be the risky decision to take another 
distro's
binary package and try to use it on the system.  It can work, it can't work,
but it's still an option.

Note that this could also make debugging system breaks a little harder.

You may not find the feature useful, but I sure as hell would have found it
useful, especially for tracking down dirty dependency breaks from compiling
packages using make.  That way I wouldn't have to start off compiling from the
beginning every single time I change a variable.

Also, if you find the code too duplicated, please rewrite the code or put in
some suggestions for fixing that.  I am by no means an expert Bash scripter,
and this was just to be quick and dirty for review.

Conluding: In my opinion, this _increases_ Sorcery's functionality by not
constraining an admin to the package management system as the only and correct
way of installing a package.  Please tell me of any package managers that have
a virtualization function for their package management that is custom by the
administrator's wants or necessities, not because the package manager's
developers said so (as is with the case of Gentoo and a couple of their
packages).

While virtualization should not be relied upon by Grimoire developers out of
laziness, it should be an option available to an administrator if they wish to
do it.  Inexperienced admins would not necessarily know exactly what to do 
with
virtualizing packages, while experienced admins can find this a helpful 
option.

-- 
Configure bugmail: http://bugs.sourcemage.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.