dj at linuxfromscratch.org
Wed Apr 2 19:08:52 PDT 2008
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
More information about the blfs-dev