Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] patchlevel policy

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: David Kowis <dkowis AT shlrm.org>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] patchlevel policy
  • Date: Thu, 08 Mar 2007 18:32:19 -0800

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.

>>>> For people with slow systems (who should already know that they're going
>>>> to be spending a lot of time compiling) and people who check every
>>>> update, we have `sorcery queue-security`. There is no reason not to use
>>>> PATCHLEVEL to force packages to be queued when that'd fix a current or
>>>> future problem.
>>> There are bugfixes that have nothing to do with security that absolutely
>>> need to present themselves as critical updates. The recent business of
>>> apache2 moving its default files around is a prime example. Yes, that was
>>> a file move, but it was a file move that broke production systems because
>>> it included things like the existing conf files and document roots being
>>> ignored.
>> A corner case, I would say, but then, my firefox issue also is a corner
>> case.
>
> How is it a corner case? Every existing apache2 install that upgraded to
> 2.0.59, patchlevel 0, could not find its configs or documents. If you mean
> the bug itself was a corner case, I don't see it as more than general
> brokeness like anything else we patch things to fix.
>
>> 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.

David

Attachment: signature.asc
Description: OpenPGP digital signature




Archive powered by MHonArc 2.6.24.

Top of Page