On Wed, Apr 2, 2008 at 7:08 PM, DJ Lucas <[EMAIL PROTECTED]> wrote: > 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.
To be fair, the BDB patches are individual with version numbers, i.e. patch.4.5.20.1, patch.4.5.20.2, etc. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
