Public SourceMage Discussion List

[Seth Alan Woolley <seth AT positivism.org>]

On Thu, Jun 30, 2005 at 10:13:58PM -0700, Eric Sandall wrote:
> Perhaps I'm misunderstanding the problem you are talking about, but the
> fix I'm talking about is:
> 
> $ gaze PRE_BUILD g++
<snip>
> 
> So g++ will not cast if gcc was not updated first. This fix is in devel,
> test, stable/0.0, and stable-rc/0.1.

Now I remember, I wanted the PRE_BUILD check to be done earlier so that 
it's caught before compiling starts.

To do this you'd have to leave the PRE_BUILD code in and add a check in 
PREPARE or DEPENDS to see if both the version is not the same and that 
gcc is not on the install queue or command-line list of stuff that will 
be installed.

That way, when g++ is added to the queue, you can get queried so that 
you can add it to the dependency list forcefully (the only check sorcery 
does right now is that the spell is installed).

* * *

Regarding sorcery, it would be nice if (at a very minimum) we could 
force a dependency to be recompiled (added to the install queue), even 
if it's already installed so we could have spells handle the versioning 
that they need with a very simple addition to the api: depends_force 
$SPELL.  This should be all you need to enable graceful spell-based 
fixes to a small number of complicated spells with complex dependencies

* * *

Perhaps you can give the spell more explicit control over dependency 
versioning such as:

depends_version $SPELL $VERSION-GLOB-LIST

VERSION-GLOB-LIST could be a space-delimited list of globs that will 
match a valid version that the spell compilation is compatible with -- 
if the version of SPELL didn't match the VERSION-GLOB-LIST, it would 
force a recompile if the new spell's VERSION correctly matches the 
VERSION-GLOB-LIST, otherwise it will fail the spell and ask for a bug 
report.  The VERSION-GLOB-LIST can even be derived from the existing 
spell VERSION for some spells that may have a sister spell that is only 
compatible when they have consistent major version numbers, so that 
VERSION-GLOB-LIST doesn't need to be updated all the time.  I think a 
glob would be easier than a regex for new spell authors unless we want 
to make regex knowledge a requirement for spell authors (globs are 
pretty simple and powerful enough, I believe).  I also think it avoids 
the problem with trying to figure out the cardinality between two 
different versions of a spell (other distros will allow you to specify 
expressions something like "> 4.33", but I think that's overkill and 
will be too complex for all versioning formats available).

That might be an easy way to add elementary versioning support in the 
dependency system, but I'm leaning toward not going to advanced 
versioning support all over the place in sorcery because it requires so 
much more maintenance to be accurate and we instead have grimoire 
versioning that should be mostly internally-consistent.  The only places 
where version dependencies should be added are in spells that need it 
for an upgrade between an immediately previous version of stable 
grimoire and the stable grimoire it will appear in.  We shouldn't worry 
about backwards compatibility with things that haven't been in stable 
grimoire for a while.

-- 
Seth Alan Woolley [seth at positivism.org], SPAM/UCE is unauthorized
Quality Assurance Team Leader & Security Team: Source Mage GNU/linux
Linux so advanced, it may as well be magic http://www.sourcemage.org
Secretary Pacific Green Party of Oregon http://www.pacificgreens.org
Key id 00BA3AF3 = 8BE0 A72E A47E A92A 0737  F2FF 7A3F 6D3C 00BA 3AF3

Attachment: pgpDuOKB_eYwT.pgp
Description: PGP signature