The ebuild for docker (currently 1.3.3 and 1.4.0) both have a dependency on >=sys-fs/btrfs-progs-3.16.1. This version requirement is higher than what docker depends on. Docker only requires btrfs-progs-3.8 (as documented here: https://github.com/docker/docker/blob/master/project/PACKAGERS.md#build-dependencies). The documentation does however state that if you are using a btrfs-progs version older than 3.16.1 you need to set a build parameter because of a missing header file (as documented here: https://github.com/docker/docker/blob/master/project/PACKAGERS.md#docker_buildtags). This version requirement is an issue as btrfs-progs-3.16.1 is not marked stable. The version requirement in the ebuild should match the upstream version requirement. In short, change the btrfs requirement to: `>=sys-fs/btrfs-progs-3.8` and add `DOCKER_BUILDTAGS+=" btrfs_noversion"`.
app-emulation/docker isn't stable either. For simplicity only I'd rather keep current version dependency. Does running btrfs-progs-3.16.1 with kernels >=3.8 and < 3.16.1 creates any issues? IMHO that would be the only valid reason to relax the dependency.
Just because a package isn't marked stable isn't justification for it requiring other unstable packages. What if some other stable package is incompatible with btrfs-progs-3.16.1? You wouldn't be able to install both docker and this other package at the same time. This dependency also prevents the docker ebuild from ever being marked as stable (not saying btrfs-progs is the only blocker, just one of them).
I should also add that if your reasoning is to avoid the complexity of adding one line to the ebuild, then all you're doing is shifting that complexity elsewhere. By requiring a non-stable version of btrfs-progs, you're requiring users to put in a keyword override for it. And then what if the user puts in a keyword override for that specific btrfs-progs version, but that version gets yanked and another unstable one replaces it? Now the user has to go and fix the override.
(In reply to Patrick from comment #3) > I should also add that if your reasoning is to avoid the complexity of > adding one line to the ebuild, then all you're doing is shifting that > complexity elsewhere. > By requiring a non-stable version of btrfs-progs, you're requiring users to > put in a keyword override for it. And then what if the user puts in a > keyword override for that specific btrfs-progs version, but that version > gets yanked and another unstable one replaces it? Now the user has to go and > fix the override. Those things are handled by arch teams when the given package is stabilized. They make sure that all reverse dependencies are stable too. I can assure you that whenever docker is stabilized on Gentoo it will merge cleanly on stable system. Since you're using unstable package (docker) you cannot expect it to have only stable deps. BTW, you can use various operators in package.accept_keywords, like: >= You don't need to update the file every time btrfs-progs is bumped.
(In reply to Kacper Kowalik (Xarthisius) from comment #4) > (In reply to Patrick from comment #3) > > I should also add that if your reasoning is to avoid the complexity of > > adding one line to the ebuild, then all you're doing is shifting that > > complexity elsewhere. > > By requiring a non-stable version of btrfs-progs, you're requiring users to > > put in a keyword override for it. And then what if the user puts in a > > keyword override for that specific btrfs-progs version, but that version > > gets yanked and another unstable one replaces it? Now the user has to go and > > fix the override. > > Those things are handled by arch teams when the given package is stabilized. > They make sure that all reverse dependencies are stable too. I can assure > you that whenever docker is stabilized on Gentoo it will merge cleanly on > stable system. I'm not concerned about when docker gets merged to stable, I was only pointing out supporting arguments for why this dependency shouldn't exist. > Since you're using unstable package (docker) you cannot expect it to have > only stable deps. I don't. I expect the ebuild to not require things it doesn't need. > BTW, you can use various operators in package.accept_keywords, like: >= You > don't need to update the file every time btrfs-progs is bumped. Yes, but doing things like prevents the system from ever going back to a stable version. Portage will always pull in unstable versions as long as a `>=` keyword exists.
https://github.com/docker/docker/blob/master/project/PACKAGERS.md#build-dependencies > btrfs-progs version 3.16.1 or later (unless using an older version is absolutely necessary, in which case 3.8 is the minimum and the note below regarding btrfs_noversion applies)
I'm not completely opposed to some intelligent logic for setting "btrfs_noversion" based on the current btrfs-progs version (preferably with an ewarn for older versions), but I'm definitely opposed to setting it universally regardless of the btrfs-progs version.
<QA hat> The version requirement will stay untoched, unless someone can provide us full tests that all functionality of docker works fine with lower versions of btrfs-progs. We do not want to go against upstream and they recommend at least 3.16.1 or in rarer cases, if you want to go on your own - at least 3.8. That means, in our terms, that in distribution wide terms, we should stick to 3.16.1 and you, as user, may utilize package.provided and setup version, that you think is most suitable for your system. Gentoo tree-wide policy claims that: 1) stable package can have only stable dependencies, no unstable or masked packages in deps; 2) unstable packages can have both stable and unstable dependencies. We do not need to prefer stable ones against unstable. No masked packages should be in dependencies. Of course, maintainer is free to do some work(it's amount depends on specific packages) to provide support for this configuration: patching, testing, etc. But it's not obligatory to support non-upstream recommended configuration, that is not forced by Gentoo policies. So, relying on all this info and previous comments of the maintainer, i am closing this bug as WONTFIX </QA hat>
