Public SourceMage Discussion List

[David Kowis <dkowis AT shlrm.org>]

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