>>>>> "SG" == Stephen Gallagher <sgallagh@xxxxxxxxxx> writes: SG> Right now, we have a policy that essentially forbids source code SG> from being bundled into a package. Technically we only care if that bundled code is actually compiled in. SG> In technical terms, this means essentially that the packaging SG> policies mandate that any code that appears more than once in the SG> repository must be turned into a shared library and dynamically SG> linked into any package that requires it. We're happy with static libraries as well, though of course dynamic libs are preferable because then you really only need to fix issues in one place. SG> Any package that wants an exception to this must petition the Fedora SG> Packaging Committee and get an explicit exemption from this policy. SG> This process is heavyweight and sometimes inconsistent in how the SG> decision is made. We try to be consistent, but the committee does change over time as do the opinions of the committee members. If you have examples of what you believe to be inconsistencies, please feel to raise them. I'm guessing that most of the complaints would stem from FPC allowing Firefox but not whatever other program. SG> I would like to propose that the no-bundled-libraries policy be SG> amended as follows: "Any package that has an existing mechanism to SG> link against a shared system library and functions correctly when SG> doing so must link against that library and not bundle it SG> internally. Any package whose upstream releases cannot link against SG> a shared system library (or are incompatible with the version in SG> Fedora) may bundle that library (without requiring a special SG> exemption) but MUST add Provides: bundled(<libname>) = <version> in SG> the spec file for each known bundled library. Which is same as the current policy, minus anyone actually caring whether this really happens. I would not object to a weakening of the rules (and in fact I've pushed a weakening of the rules before, leading to the current situation being less strict than it was previously). I would object rather strenuously to just not bothering. SG> The reason for this proposal is relatively simple: we know the SG> advantages to unbundling, particularly with security and resource- SG> usage. However, the world's developer community largely *does not SG> care*. We fought the good fight, we tried to bring people around to SG> seeing our reasoning and we failed. We haven't really failed, though. Good work has come of this, and if we resist these bad habits then more good work can come of it, even to the upstreams which currently resist. SG> The point of software is to provide a service to an end-user. Users SG> don't run software because it has good packaging policies, they run SG> software because it meets a need that they have. One could make the same argument for open source in general. SG> If they can't get that software from Fedora, they *will* get it from SG> another source (or use a different OS that doesn't get in their SG> way). Exactly. Let's ship binary drivers. I know that's something of a straw man, but my point is that we must have some principles, and must work with upstreams to attempt to get them to at least understand those principles. And we shouldn't give up on that just because someone wants some program which is easily provided by a copr anyway. - J< -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
