Skip to Content.
Sympa Menu

sm-sorcery-bugs - [SM-Sorcery-Bugs] [Bug 8060] New: better UPDATED handling

sm-sorcery-bugs AT lists.ibiblio.org

Subject: Bugs for Sorcery are reported here

List archive

Chronological Thread  
  • From: bugzilla-daemon AT bugs.sourcemage.org
  • To: sm-sorcery-bugs AT lists.ibiblio.org
  • Subject: [SM-Sorcery-Bugs] [Bug 8060] New: better UPDATED handling
  • Date: Fri, 21 Jan 2005 17:07:43 -0800 (PST)

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

Summary: better UPDATED handling
Product: Sorcery
Version: Untargetted future release
Platform: Other
OS/Version: other
Status: NEW
Severity: normal
Priority: P2
Component: Sorcery
AssignedTo: sm-sorcery-bugs AT lists.ibiblio.org
ReportedBy: seth AT tautology.org


> > > > spell imaginary-spell is added with version 1 in the distant past
> > > >
> > > > spell imaginary-spell is updated with a security patch on day 1 to
> > > > devel
> > > >
> > > > on day 7 test grimoire is re-downloaded on computer-foo.
> > > >
> > > > on day 7 imaginary-spell is recompiled via a sorcery rebuild
> > > > (or maybe an update from version 0)
> > > >
> > > > spell imaginary-spell is updated on day 14 to test with security patch
> > > >
> > > > ***problem cause*** The UPDATED value is listed as "day 1"
> > > >
> > > > on day 20, computer-foo is updated.
> > > >
> > > > with UPDATED listed as day 1 on imaginary-spell and compile date is
stored
> > > > as day 7, imaginary-spell's security update is not triggered for
recompile
> > > >
> > > > I'm just hoping for some way to avoid that. This also happens when
> > > > scribe update is run a time significantly before an update, not just
> > > > when we have lagged updates to the grimoire.
> > >
> > > Didn't you think about a PATCHLEVEL variable some time ago that was used
> > > for updates instead of the date based UPDATED? I think that would solve
> > > this problem easily.
> >
> > Yeah, I did. I also thought there might be a solution that didn't
> > require any additional guru overheard, but the patchlevel variable might
> > be what we should use, instead.
> >
> > Are we prepared to support PATCHLEVEL instead of UPDATED? IF we use
> > PATCHLEVEL, UPDATED (or a new PATCHRECOMPILE variable) should probably be
> > changed to match the patchlevel that is a suggested recompile instead of
> > being the date.
> >
> > patchlevel 1 - new features to spell but not a change in compile
> > patchlevel 2 patchrecompile 2 - should recompile
> > patchlevel 3 patchrecompile still 2 - should recompile only if
> > patchlevel was less than 2
> >
> > We should have an implied default patchlevel of 0 so the variable(s)
> > is(are)n't needed.
> >
>
> Couldnt we just record the value of UPDATED somewhere (like in the
> tablet) when a spell is cast then we'd just compare the new value of
> UPDATED with the last one instead of comparing it with the date installed
> (which i agree is wrong, and shouldnt have been that way)
>
> This will solve your problem without this complicated patchlevel scheme.

better UPDATED handling like in the two paragraphs above.

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



  • [SM-Sorcery-Bugs] [Bug 8060] New: better UPDATED handling, bugzilla-daemon, 01/21/2005

Archive powered by MHonArc 2.6.24.

Top of Page