Public SourceMage Discussion List

[Jeremy Blosser <jblosser-smgl AT firinn.org>]

On Mar 08, David Kowis [dkowis AT shlrm.org] wrote:
> Jeremy Blosser wrote:
> > 
> > Forget that one for a minute -- we currently make them recompile for file
> > location changes that don't break anything, eg if a man page changes
> > location.  Assuming man could already find it, what is broken there that
> > needs fixing?
> > 
> 
> Yeah that's really annoying. I've never liked having to recompile
> something just to fix a small file glitch. Like, for example, the glibc
> recompile to acquire the new timezone files.

We had a patch for this?  I thought it just came in as part of glibc 2.3.6
or whatever it was.  It was fixed upstream well ahead of the change AFAIK,
we shouldn't have needed to push it out early.

> >> Perhaps we should come up with a usage policy for PATCHLEVEL that
> >> pleases the both of us: * PATCHLEVEL will always be incremented if
> >> there is a change to the location of installed files * PATCHLEVEL will
> >> always be incremented if other packages always require this change to
> >> work * PATCHLEVEL may be incremented on a case-by-case bases for other
> >> uses (such as a new configuration option)
> > 
> > My understanding is this is essentially what we do now, and it's not good
> > for me without further definition of which file moves matter or which
> > packages require it.  This is why I suggested something like a major and
> > minor patchlevel.  The minor could go along with the things you listed
> > there, while the major would only be incremented if a spell is patched to
> > fix some level of brokeness for some percentage of users ("some" yet to be
> > defined in both cases).
> > 
> > Then people who want it all can use the regular queue, and people who 
> > don't
> > want minor stuff can use a queue-critical or something.
> > 
> 
> Yes, some sort of prioritized queue ability would be preferential here.
> 
> queue --all
> queue --security
> queue --functional
> 
> or whatever levels of patchworthyness we define
> Major.Minor.Patchlevel doesn't really apply here so it'd be better to
> have them
> 
> PATCHLEVEL=security.functional.trivial
> 
> If we want to conserve our variables. Just some thoughts.

SECURITY_PATCH is already separate and needs to be because it doesn't get
reset between version updates and is used to indicate if even the version
update itself is a security patch.

Of course that starts to beg the question if we should similarly indicate
if other version updates are new features vs critical functional updates.
I doubt we want to open the can of needing to know if an upstream release
should be considered a critical update or not, though.

Attachment: pgpvcZYeetAcd.pgp
Description: PGP signature