Upstream patches

[Dan Nicholson]

On Wed, Apr 2, 2008 at 7:08 PM, DJ Lucas <dj at linuxfromscratch.org> 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