Bug 1233581

I'm going to argue this point, not because I feel like arguing, but because I'm trying to determine the best solution and I find that talking through the options helps with that process.

In Fedora, we think that if package A bundles package B, that is bad and A ought to be patched to unbundle B.  If package C breaks as a result, because it assumes that A bundles B, doesn't that make C just as bad, and just as in need of patching, as package A?

Also, if we alter the subunit package to include a symlink to a file not owned by the subunit package, that opens the possibility of the link being broken by some future change to the python-iso8601 package, such as it changing from noarch to arch-specific, or dropping python 2 support, or simply renaming its files.

So I propose that whatever packages you have come across that are broken by the unbundling ought to be patched, not subunit.  Counterarguments?

(In reply to Jerry James from comment #1)
> I'm going to argue this point, not because I feel like arguing, but because
> I'm trying to determine the best solution and I find that talking through
> the options helps with that process.

Sure, thanks for this.

> In Fedora, we think that if package A bundles package B, that is bad and A
> ought to be patched to unbundle B.  If package C breaks as a result, because
> it assumes that A bundles B, doesn't that make C just as bad, and just as in
> need of patching, as package A?

Sure, we can do this downstream but:
- I think that if possible, we should make the unbundling patches transparent - in the sense that they don't make (possibly all) depending packages adapt.
- We should also think of usecases when developers do "pip install --user package-that-depends-on-A". Since we can't control these, we should (again, if possible) make the unbundling patches transparent.

> Also, if we alter the subunit package to include a symlink to a file not
> owned by the subunit package, that opens the possibility of the link being
> broken by some future change to the python-iso8601 package, such as it
> changing from noarch to arch-specific, or dropping python 2 support, or
> simply renaming its files.

That's true, but let me have a suggestion:
We have a system called Koschei [1] that does "CI" for packages. It basically has a priority queue of packages to continuously rebuild and bumps the priority when a dependency of package is rebuilt. What if you included a test for the iso8601 file in %check section and added your package to Koschei? That way, you should be notified (it emits messages that can be filtered out using FMN) in the event that something changes.
If python-iso8601 drops Python 2 support, then the situation would be the same as it would be now, since you'll still have "Requires: python-iso8601", IIUC.

> So I propose that whatever packages you have come across that are broken by
> the unbundling ought to be patched, not subunit.  Counterarguments?

[1] http://koschei.cloud.fedoraproject.org/

Jerry, any further thoughts/concerns? If not, can you get this fixed, please? Thanks a lot!

Sorry, Real Life's been keeping me very busy lately.  I am on the road, and will be for the next week.  I can't really build anything without a Fedora box with me.  If you can get a provenpackager to take care of this, please go ahead.  Otherwise, I will deal with it when I get home on July 20th.

Fixed in [1], built as subunit-1.1.0-3.fc23.

[1] http://pkgs.fedoraproject.org/cgit/subunit.git/commit/