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 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
