Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] stable-rc call for testing (and depends_force or glob-based depends?)

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Seth Alan Woolley <seth AT positivism.org>
  • To: Eric Sandall <eric AT sandall.us>
  • Cc: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] stable-rc call for testing (and depends_force or glob-based depends?)
  • Date: Sat, 2 Jul 2005 19:45:56 -0700

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




Archive powered by MHonArc 2.6.24.

Top of Page