Opened 16 years ago

Closed 16 years ago

#2164 closed task (fixed)

Berkeley DB-4.4.21 Patch

Reported by: randy@… Owned by: Jeremy Huntwork
Priority: normal Milestone: 7.0
Component: Book Version: SVN
Severity: normal Keywords:
Cc:

Description

There's a patch that should be applied to the Berkeley-DB instructions in Chapter 6. See the BDB home site.

Change History (4)

comment:1 by Jeremy Huntwork, 16 years ago

Owner: changed from lfs-book@… to Jeremy Huntwork
Status: newassigned

Direct link to the patch and explanation (took me a couple of seconds to spot it on the home page): http://www.oracle.com/technology/products/berkeley-db/xml/update/4.6.21/patch.4.6.21.html

comment:2 by Jeremy Huntwork, 16 years ago

Resolution: fixed
Status: assignedclosed

Fixed with #8505

comment:3 by randy@…, 16 years ago

Resolution: fixed
Status: closedreopened

It is not the right thing to do to copy the upsteam patch, and hope it is never modified upstream.

This patch should be downloaded from upstream and applied to the book.

We have no business recreating it, as it is upstream to decide what patches should belong to a package.

This is on the knowledge that upstream has modified patches, but not changed the name in the past. Which makes any copied patch obsolete and probably wrong.

comment:4 by Jeremy Huntwork, 16 years ago

Resolution: fixed
Status: reopenedclosed

This is standard LFS procedure. We always redistribute the patches. Look at how the Bash fixes are done, for example. This patch was created by copying their patch verbatim, applying it and re-diffing it. The only reason it was re-diffed was to be consistent with all the other patches that are applied with -p1 instead of -p0.

If they are likely to change the patch without changing the name, and we link directly to it from the book, then we could hit the situation that we at some point have a link to a patch that is untested. If we take from their site now and redistribute it in our internal format, then at least we are working with something known and unchanging (until we change it.) When and if they do change the patch, then we can test and possibly upgrade the one we have.

Either way, this is LFS policy we're talking about. Therefore, closing as fixed again. If you have a policy issue to raise, create a new ticket specific to that and/or bring it up to lfs-dev.

Note: See TracTickets for help on using tickets.