Public SourceMage Discussion List

[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
                    


-- 
Seth Alan Woolley [seth at positivism.org], SPAM/UCE is unauthorized
Key id EF10E21A = 36AD 8A92 8499 8439 E6A8  3724 D437 AF5D EF10 E21A
http://smgl.positivism.org:11371/pks/lookup?op=get&search=0xEF10E21A
Security Team Leader Source Mage GNU/Linux http://www.sourcemage.org

Attachment: pgp7t0dXh9c2f.pgp
Description: PGP signature