Bugs for Sorcery are reported here

[bugzilla-daemon AT bugs.sourcemage.org]

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


Andraž 'ruskie' Levstik <ruskie+bugs AT codemages.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ruskie+bugs AT codemages.net




--- Comment #3 from Andraž 'ruskie' Levstik <ruskie+bugs AT codemages.net>  
2009-02-28 00:31:44 ---
> 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.

delve --help

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

Because it doesn't have any init scripts defined. You could provide a patch to
the spell that installs the init scripts and that's done.

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

There's libpatch that I wrote exactly for this... ability to apply custom
patches at compile time(similar to config_loc option).
http://bugs.sourcemage.org/show_bug.cgi?id=7296

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

Could have written a module for quill that allows creating spells out of 
those.


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

Again: delve --help

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

A local grimoire with the relevant changes  as one wants is just as easy to
setup without needing virtualized packages.

Just my own 0.02 eurocents...

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