ebuild-writing/bundled-dependencies: new section #377
Conversation
|
How's it looking now? OK to proceed to content review? And do we want to commit this as-is, or review the content here? Either is fine with me. I guess reviewing the content here is easier because you can comment on the full diff more easily. What I don't want to do, however, is squash any content fixes into the first commit. |
|
I'd say we should continue with content review here. |
|
Let me know when it looks OK and I'll move onto content (I don't want to try fix existing style issues in the first commit once I started that, as cherry-picking that will be hell). |
ulm
left a comment
ulm
left a comment
There was a problem hiding this comment.
Formatting looks good.
I have some tiny comments, admittedly most are into spelling territory (but you might want to fix them now, so they won't interfere with content review later).
I've tried to faithfully port the wiki page [0] to the devmanual in this commit, and intend to change the contents as required in followups, to allow easier comparison and to retain provenance. [0] https://wiki.gentoo.org/wiki/Why_not_bundle_dependencies Closes: https://bugs.gentoo.org/300625 Signed-off-by: Sam James <[email protected]>
|
Thank you! The quick reviews are appreciated, it helps a lot with momentum and motivation. |
laumann
left a comment
laumann
left a comment
There was a problem hiding this comment.
This is good reading 👍
idk if you want examples of packages where upstream does vendor dependencies, but has a mechanism not to use them. media-libs/openjpeg vendors some libraries that Gentoo's packaging carefully removes. At least it's optional to use the vendored versions.
| <p> | ||
| Especially in Windows, shipping dependencies <e>can</e> be a favour to users | ||
| to save end users having to manually install dependencies or additional | ||
| libraries. Without a package manager, there is no real-solution to that on |
There was a problem hiding this comment.
Intentional hyphen? Suggestion: real-solution → real solution.
| Bundling <e>D</e> hides the dependency on <e>D</e> in a way: if the packager | ||
| is not paying close attention <e>P</e> may even get in despite and with the | ||
| bundled dependency. (It is, however, only a matter of time until someone | ||
| noticed the bundling.) |
| </p> | ||
|
|
||
| <p> | ||
| Now, a very important security flaw has been found in <e>libbar</e> |
There was a problem hiding this comment.
"very" is a weasel word - maybe "critical security flaw"?
| of <e>libbar</e> release fixed version right away, and distributions package | ||
| it quickly to decrease the possibility of break-in to users' systems to | ||
| minimum. |
There was a problem hiding this comment.
I think this is missing some as:
- release a fixed version
- to a minimum
| </ul> | ||
|
|
||
| <p> | ||
| In the meantime, users probably even won't know they are a running vulnerable |
| are aware that the package is statically linked) | ||
| </li> | ||
| <li> | ||
| If <e>foo</e> bundled local copy of <e>libbar</e>, then they would have to wait |
| Once it is clear that a bundled dependency can be ripped out, a patch is | ||
| written, applied and tested (more waste of time). If upstream is willing to | ||
| co-operate the patch may be dropped later. If not the patch will need | ||
| porting to each now version downstream. |
3 participants
I've tried to faithfully port the wiki page [0] to the devmanual in this commit, and intend to change the contents as required in followups, to allow easier comparison and to retain provenance.
[0] https://wiki.gentoo.org/wiki/Why_not_bundle_dependencies
Closes: https://bugs.gentoo.org/300625
Note: I'm looking for review of the formatting and porting to the devmanual for now, not whether we should add/adjust content etc (which I will do once the foundation is OK).