Public SourceMage Discussion List

[Eric Sandall <eric AT sandall.us>]

Quoting Seth Alan Woolley <seth AT positivism.org>:
> On Sat, May 01, 2004 at 05:08:23PM -0700, Seth Alan Woolley wrote:
> > Hi SMGLers,
> > 
> > I propose we support a PATCHLEVEL variable, entirely optional, but if it
> > is set, it would add a suffix to the VERSION for what gets recorded in
> > the sorcery state information (for gaze version and when to figure out
> > when to recompile).
> > 
> > This would mean a spell that has a SOURCE_DIRECTORY of $SPELL-$VERSION
> > wouldn't need to be edited all over the place to add a simple patchlevel
> > for a security update that is not part of the standard vendor
> > distribution path (say the vendor is on a break or something or it's a
> > long time between releases even with security updates in the queue).
> > 
> > This would eliminate the need to use UPDATED or CREATED.  Both of these
> > are covered in the HISTORY as far as I'm concerned, and it seems like
> > unneeded maintanence.  If PATCHLEVEL goes in, I'd like to see these two
> > fields deprecated and removed from devel/test after the next stable
> > integration.
> > 
> > I don't have a patch to implement this yet, but I could whip one up. 
> > 
> > Implementation would just require that PATCHLEVEL (and optionally
> > FULL_VERSION) be added to the list of variables that are cleared in
> > run_details and have some small magic after run_details until cast is
> > complete and written to the sorcery state information to change VERSION
> > to FULL_VERSION, where FULL_VERSION="$VERSION-$PATCHLEVEL" if PATCHLEVEL
> > is defined, else FULL_VERSION="$VERSION".  At the same time, one could
> > check to see if FULL_VERSION is set at that point and opt to use it
> > instead of doing the VERSION-PATCHLEVEL concatenation if say the version
> > used in the filename is so far off whack you want to totally rewrite it.
> > 
> > Comments?
> 
> So we started discussing this in the irc channel and it looks like a
> separate PATCHLEVEL= variable would work better, one that is an added
> field in the packages file:
> 
> 17:19 <+dufflebunk> So what happens if they release version 4.3.1-1 next?
> 17:24 <@swoolley> dufflebunk: what do you mean?
> 17:24 <@swoolley> 3.2.1 as 3.2.1-1 and then they release 4.3.1-1 or 4.3.1?
> 17:25 <@swoolley> PATCHLEVEL is just to make it different so sorcery knows 
> to
> recompile it.
> 17:25 <+dufflebunk> they release 3.2.1-1
> 17:25 <@swoolley> they release 3.2.1-1, then VERSION=3.2.1-1 and PATCHLEVEL
> line is deleted.
> 17:26 <@swoolley> if a patch is added, it becomes 3.2.1-1-1
> 17:26 <+dufflebunk> But people will look at the version and note that they
> already have 3.2.1-1
> 17:26 <@swoolley> no, sorcery handles recompiling
> 17:26 <+dufflebunk> You want to add parsing to the version string??
> 17:27 <@swoolley> no, I'm not adding parsing to it!
> 17:27 <@swoolley> it will never be parsed, this is just to make it
> _different_
> 17:27 <@swoolley> why?
> 17:27 < ruskie> don't we have the UPDATED field for that?
> 17:27 <@swoolley> UPDATED is unreliable
> 17:27 <@swoolley> let's say we make a fix and it's in test and devel, but 
> not
> stable
> 17:28 <@swoolley> they recompile the older version of the spell after the
> UPDATED is incremented
> 17:28 <+dufflebunk> You need to put the information in the version field of
> the packages file, right?
> 17:28 <@swoolley> the spell gets integrated to stable grimoire
> 17:28 <@swoolley> they do sorcery system-update and they have no clue a 
> newer
> version of the spell is out.
> 17:29 <@swoolley> it's only reliable if they always have an updated grimoire
> the minute they finish recompiling (an impossible task)
> 17:29 <@swoolley> let's say there's a fix on day 1, and it goes in the
> grimoire.
> 17:30 <@swoolley> somebody upgrades their grimoire before the fix is
> committed on day 1.
> 17:30 <@swoolley> they recompile on day 2
> 17:30 <@swoolley> then they download the new grimoire which says it was
> upgraded on day 1
> 17:30 <@swoolley> their day 2 compile looks new when it isn't and all they
> did was have a day old grimoire.
> 17:31 <@swoolley> if they compile something on day 1 and it finishes on day
> 2, the same thing would happen.
> 17:31 <@alley_cat> looks like a good idea to me, as long as it is never
> displayed anywhere (except with maybe gaze patchlevel)
> 17:32 <@swoolley> alley_cat: yeah, we could keep it out of VERSION, period,
> and add a gaze to it, I like that idea better.
> 17:32 <@swoolley> or add an extra field to gaze version to include the
> patchlevel.
> 17:32 <@alley_cat> yeah
> 17:32 <@alley_cat> as long as version always refers to the version of the
> software i'm fine with it
> 17:33 <@alley_cat> it's basically a more reliable replacement for UPDATED
> 17:33 <+dufflebunk> But you have to store the patch level information in the
> packages file. This will require either a new field (and modifying many
> disparate chinks of sorcery), or adding it to the cirrent version field,
> which will require parsing of the field.
> 17:34 <@swoolley> I'm sorry I opened a can of worms ;)
> 17:34 < ruskie> then why not simply dump the UPDATED field and just use
> PATCHLEVEL?
> 17:34 <@swoolley> ruskie: that's what I want -- except patchlevel doesn't
> exist yet.
> 17:34 <+dufflebunk> ruskie: There are still occasionaly reasons to just use
> UPDATED
> 17:35 < ruskie> but patchlevel should be disticnt in the name since it would
> be mostly useless to ppl...
> 17:35 < ruskie> so that it could be easily parsed out
> 17:35 <@swoolley> one could use PATCHLEVEL=1.1?
> 17:35 <@swoolley> major patchlevels mean source actually modified, minor
> means the spell changed slightly in a bugfix?
> 17:36 <@alley_cat> doesn't really matter imho which it is
> 17:36 < ruskie> hmm that acctually sounds nice
> 17:36 <@alley_cat> if the spell needs to be recompiled, updated PATCHLEVEL,
> otherwise don't
> 17:36 <@alley_cat> everything else can be seen in the history file
> 17:36 <@swoolley> yeah.
> 17:37 <@swoolley> we could just convert fractional patchlevels to integers
> before doing the check for sorcery queue.
> 17:37 <@swoolley> but that's too much work when it's in history.
> 17:37 <@alley_cat> the problem is storing it in the packages file
> 17:38 <@swoolley> that's why I just wanted it thrown on the end of the
> version, but that's too unclean, I guess.
> 17:38 <@alley_cat> that doesn't work
> 17:38 <@alley_cat> at least not with a common seperator like -, . _ or
> something
> 17:38 < ruskie> you can have a version of 3.2.1-1-1 then
> 17:38 <@swoolley> we can add an extra field
> 17:38 <@swoolley> the version is at the end anyways.
> 17:39 < ruskie> the packgaes file is the problem
> 17:39 <@alley_cat> i think adding another field at the end is the cleanest
> way, but i don't know where that could screw up sorcery
> 17:39 <@swoolley> if one adds an extra field, cuts on it will be blank, 
> which
> is the preferred default anyways.
> 17:41 <@alley_cat> at least gaze version doesn't break if there's another
> field at the end of a line in packages :P

I think this sounds like a good idea. What do we need to test/implement this?

-sandalle

-- 
Eric Sandall                     |  Source Mage GNU/Linux Developer
eric AT sandall.us PGP: 0xA8EFDD61  |  http://www.sourcemage.org/
http://eric.sandall.us/          |  SysAdmin @ Inst. Shock Physics @ WSU
http://counter.li.org/  #196285  |  http://www.shock.wsu.edu/

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.