Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] PATCHLEVEL (and perhaps FULL_VERSION) variable in DETAILS proposal

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Seth Alan Woolley <seth AT positivism.org>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] PATCHLEVEL (and perhaps FULL_VERSION) variable in DETAILS proposal
  • Date: Sat, 1 May 2004 17:51:12 -0700

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




Archive powered by MHonArc 2.6.24.

Top of Page