Ticket #160 (closed task: fixed)

Opened 2 years ago

Last modified 2 years ago

Bundling exception request for Passenger

Reported by: wakko666 Owned by: spot
Priority: minor Milestone:
Component: Bundled Library Exception Version:
Keywords: Cc:
Blocked By: Blocking:

Description

This is a request to grant a bundling exception for rubygem-passenger (aka. mod_passenger, Passenger), which bundles a forked version of Boost.

Here's the package review request in Bugzilla, with it's very long history: https://bugzilla.redhat.com/show_bug.cgi?id=470696

I have been working with the upstream Boost community to get as much of Passenger's fork merged as possible:

  1. http://marc.info/?t=132269010900002&r=1&w=2
  2. http://marc.info/?t=132266986500004&r=1&w=2
  3. http://marc.info/?t=133009560600002&r=1&w=2



As I chip away at reducing the differences between Passenger's bundled copy of Boost and the upstream version, it is becoming clear that there is going to be a few modifications that are unlikely to be accepted upstream.

The issues raised in the third thread listed above regarding the modifications to Boost's Exception class inheritance in order to support throwing stacktraces are legitimate concerns. The changes are fairly specific to Passenger's implementation and might present maintenance problems upstream if they're merged.

Passenger also includes some changes to Boost's signal handling that are highly Linux-centric. These changes are also unlikely to be merged upstream because the Boost folks have a requirement for being cross-platform that the Passenger changes ignore almost completely. In order to upstream this, we would need to implement the cross-platform support required by the Boost community.

Due to the way Passenger's changes integrate with the core Boost class structure, it is not possible to extract Passenger's changes.

Due to the implementation details, I do not believe that releasing a separate forked version of Boost adds significant value and is worth the effort.

Boost is licensed under a modified BSD license and appears to be neutral toward bundling. In some cases, bundling appears to be expected. Passenger uses a stock BSD license, but I have received permission from the Passenger folks that any of the forked changes that get accepted upstream may be relicensed under the Boost License.

Due to the potential long-term maintenance burden, I don't believe Fedora's Boost package is an appropriate place for these changes. In addition, the Passenger folks have consistently demonstrated that they are actively updating their forked Boost with regular updates to the latest upstream release of Boost. They are porting their changes forward on a regular basis and appear to be committed to doing so for the foreseeable future.

Finally, if Passenger is granted an exception, my work on upstreaming the forked changes will not cease. I will continue to push the forked changes upstream until I reach a minimum changeset that upstream won't accept. At that time, I will reevaluate the merits of maintaining that changeset elsewhere (e.g. the Fedora Boost rpm), and attempt to remove the bundled copy. I have already received help from the Passenger developers for adding support to build Passenger against a non-bundled Boost. So, as soon as a non-bundled Boost includes support for Passenger's requirements, then Passenger should "just work" with it.

Change History

comment:1 follow-up: ↓ 3 Changed 2 years ago by spot

  • Owner set to spot
  • Status changed from new to assigned

This bundling exception was approved, contingent on wakko666 being the maintainer (which he has confirmed he will be, post-review): (+1:5, 0:0, -1:0)

comment:2 Changed 2 years ago by spot

  • Resolution set to fixed
  • Status changed from assigned to closed

comment:3 in reply to: ↑ 1 Changed 2 years ago by kanarip

Replying to spot:

This bundling exception was approved, contingent on wakko666 being the maintainer (which he has confirmed he will be, post-review): (+1:5, 0:0, -1:0)

So after more than three years, just like that you're forcefully hijacking my package and assigning it to someone else.

Had anyone considered contacting me? You want me out of the way, I suppose?

comment:4 Changed 2 years ago by toshio

I was uncomfortable with voting +1 on the bundling exception and unfortunately, we had just enough people to make quorum at the last meeting so my +1 vote would have been necessary to pass this exception. I hurriedly tried to think of the reasons that we had not granted a bundling exception for passenger yet to see what had been or could be addressed. One of the things I remembered from past discussions was that if bundling was ongoing, the package maintainer might need to do work on the bundled boost package to backport, update, or create from scratch security fixes to the bundled library. This was something that I thought I remembered you saying was outside of your expertise. To not block on needing just one more vote to pass, the FPC agreed to stipulate that passenger could have an exception provided that wakko666 agreed to be responsible for this aspect by being the package maintainer.

If this is not satisfactory, there are other options -- as I say we only barely made quorum. So there's other packaging committee members who did not vote. We could discuss this with more members and perhaps there would be enough votes to pass a bundling exception without the maintainer provision. We might also find that there's alternatives that would be acceptable (for instance, if wakko66 agreed to be a comaintainer rather than a maintainer).

I cannot guarantee any outcome on any of these ideas; this is just the situation as it existed at the last FPC meeting.

comment:5 Changed 2 years ago by wakko666

I don't have a problem with co-maintainership of this package.

comment:6 Changed 2 years ago by spot

I don't have any issue with co-maintainership meeting this criteria.

Note: See TracTickets for help on using tickets.