dbn.lists at gmail.com
Thu Apr 3 10:22:30 PDT 2008
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.220.127.116.11, patch.18.104.22.168, etc.
More information about the blfs-dev