Upstream patches

[DJ Lucas]

Jeremy Huntwork wrote:
> Randy McMurchy wrote:
>> Upstream is notorious for changing the patch content but not changing
>> the name. And we don't see changes. This can only be a bad thing.
>> There is nothing gained by changing the patch and calling it an LFS
>> patch. This can only be a losing situation (upstream changes it, but
>> we have no way of knowing it).
> 
> As I mentioned in the Trac ticket, if they are in the habit of changing 
> the patch without changing the name, and we link directly to them, 
> essentially we open ourselves up to a situation where we link to an 
> untested (by us) patch. At least if we make a snapshot of what they 
> released, and we commit it after testing (as I did with this one) then 
> we are working with a known patch.

That is kind of a disturbing point about the way BLFS handles upstream 
patches.  I've CC'd blfs-dev too.

If the replacement patch is created with a different -P option, our 
instructions are broken.  Also, what about the recent <CR><LF> issues? 
These kinds of problems disappear if we host the patch in our own 
repository, excluding the unlikely event (or rather likely as history 
has proven) that an upstream patch is updated--which is just plain wrong 
anyway as they should have version numbers attached to them, or at very 
least, a date.  Additionally, our testing is against a known version of 
the source.  Another weak argument at best, but all other distributions 
maintain their own patch sets in their source packages.

I also don't think that it would be too difficult to create a job to 
download and check existing upstream patches against a previously 
recorded md5sum.  If this irresponsible patch updating business 
continues to occur in the future from upstream, we can easily be covered.

-- DJ Lucas