On Thu, 2015-09-10 at 10:08 -0400, Josh Boyer wrote: > On Thu, Sep 10, 2015 at 9:53 AM, Stephen Gallagher <sgallagh@redhat.c > om> wrote: > > I assume that subject line got your attention. > > > > I know this is a long-standing debate and that this thread is > > likely > > to turn into an incomprehensible flamewar filled with the same > > tired > > arguments, but I'm going to make a proposal and then attempt to > > respond to many of those known arguments up-front (in the hopes > > that > > we can try to keep the conversation on-track). Please keep the > > conversation on devel@xxxxxxxxxxxxxxxxxxxxxxx . I CCed packaging@ > > to > > make them aware of this discussion. > > > > > > > > Right now, we have a policy that essentially forbids source code > > from > > being bundled into a package. In technical terms, this means > > essentially that the packaging policies mandate that any code that > > appears more than once in the repository must be turned into a > > shared > > library and dynamically linked into any package that requires it. > > Any > > package that wants an exception to this must petition the Fedora > > Packaging Committee and get an explicit exemption from this policy. > > This process is heavyweight and sometimes inconsistent in how the > > decision is made. > > > > I would like to propose that the no-bundled-libraries policy be > > amended as follows: "Any package that has an existing mechanism to > > link against a shared system library and functions correctly when > > doing so must link against that library and not bundle it > > internally. > > Any package whose upstream releases cannot link against a shared > > system library (or are incompatible with the version in Fedora) may > > bundle that library (without requiring a special exemption) but > > MUST > > add Provides: bundled(<libname>) = <version> in the spec file for > > each > > known bundled library.(This will allow us to track down the > > bundling > > when we need to). Package maintainers should continue attempt to > > engage upstream to support linking against shared system libraries > > wherever possible, due to the advantages it provides the package > > maintainer." > > This seeks to amend the proposal for bundling within a SRPM itself. > It doesn't address the broader scope of delivering applications > outside of RPM, such as Docker containers or xdg-apps. Those also > tend to bundle, but the bundling is done within the container. In > the > case of xdg-apps, they'll need to "bundle" anything that isn't > provided by the xdg-runtime. > > Do you want to address the broader issue, or do you foresee that the > current Packaging guidelines simply won't apply to containerized apps > because they are too RPM specific? > This proposal was specifically about RPM/SRPM bundling. I think the broader issue may be impacted by any decision we make here (if we allow RPM bundling then by definition bundling has precedent). I'd prefer to keep the container/xdg/etc. discussion out of this thread for fear of making the conversation too broad. > > The reason for this proposal is relatively simple: we know the > > advantages to unbundling, particularly with security and resource- > > usage. However, the world's developer community largely *does not > > care*. We fought the good fight, we tried to bring people around to > > seeing our reasoning and we failed. > > > > > > The point of software is to provide a service to an end-user. Users > > don't run software because it has good packaging policies, they run > > software because it meets a need that they have. If they can't get > > that software from Fedora, they *will* get it from another source > > (or > > use a different OS that doesn't get in their way). I'll take a > > moment > > to remind people that two of Fedora's Four Foundations are > > "Features" > > and "First". We want Fedora to be the most feature-complete > > distribution available and we want to get there before anyone else > > does. I would say that holding to our no-bundling policy actively > > defeats our efforts on that score. > > Is the intention of your proposal to also allow Chromium into the > main > Fedora repos? I honestly can't tell where it draws the line. > I can't remember the specific issues around Chromium, so I don't necessarily want to say yea or nay there. I *thought* I remembered Chromium had issues beyond simple bundling though. If not, then I see no problems with including it if this proposal passes. > > Let me describe some of the advantages to bundling and to > > unbundling > > (as noted so we can hopefully skip some of the hotter parts of the > > flamewar). As I noted above, anything that is capable of unbundling > > should remain unbundled for its advantages. But things that are not > > currently capable (or can't be due to forwards/backwards > > compatibility > > issues, etc.) really shouldn't be forced to attempt it. > > > > > > == Advantages to using shared libraries == > > * Security/Bugs - When a bug or security vulnerability is located > > in > > a library, it needs to be patched in only a single package in > > order to > > fix all applications using that library. > > I think it's worth expanding on this a bit. Right now, the Security > team files bugs against the main instance of a library/package. The > proposal seems to help mark bundled copies, but it will still require > more time for them to file bugs against packages that bundle. > Yes, you're absolutely right. I think we can work on some automation for that, but at the end of the day it *will* mean a bit more process during those cases. I'd need to hear from the security team whether this would likely be frequent enough to be a real problem or only a minor inconvenience. > > * Resources - A shared library only needs to be loaded into memory > > once, reducing the memory requirements of the system. > > > > == Advantages to bundling == > > * Guarantees that the application is running with the same set of > > code that upstream tested. (Fewer Fedora-specific bugs means less > > burden on the maintainer) > > * Simplifies packaging of updates. (Fedora maintainer does not > > need > > to keep tabs on unbundling patches to keep in sync for new > > versions) > > * Increases the available pool of software that can be packaged > > substantially (many modern languages such as Ruby and Go are > > realistically only functional with allowable bundling) > > * Did I mention the reduction in maintainer burden yet? > > Going back to security, would you expect Fedora maintainers to patch > the bundled copy of the code to fix issues? I'm curious if that will > break some of upstream's assumptions, etc. > Well, my first recommendation would be for them to push security patches simultaneously to upstream. It's not like the patches won't be useful to upstream's community.
Attachment:
signature.asc
Description: This is a digitally signed message part
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
