2015-09-10 15:53 GMT+02:00 Stephen Gallagher <sgallagh@xxxxxxxxxx>: > 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." > Well, I won't discuss about benefits of unbundling vs bundling, this is a sterile conversation. I'll just point out that a non-negligible part of Fedora packages already bundle libraries. Unless we want to mass-review and ban all those packages, I consider that Stephen's proposal to be an *improvement* to the current situation. I would prefer that we also empower SIGs or provenpackagers to grant or not those bundling exceptions and enforce the provides thing. If you disagree, please come up with a counter-proposal even if it means dropping half of Fedora packages. Keeping status quo is at best diverting our eyes from bad practices, at worst, hypocrite. > > > 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. > > > > 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. > * 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? > > > > > Thank you for reading this far. I know that this is a topic that > people get highly passionate about, so please do your best to restrain > your responses to reasoned statments and avoid the temptation to get > angry. I'll summon up a third of our Four Foundations here: remember > that Fedora is built on "Friends" too. This should be a discussion and > not an argument. > -- > packaging mailing list > packaging@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/packaging -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
