Description of problem: There is a circular dependencies between the building of fedfs-utils and nfs-utils. nfs-utils depends on fedfs-utils-devel which is necessary for the fedfs-support in mountd to work. The building of fedfs-utils-lib depends on nfs-utils which create the circular dependency. This dependency is not needed because nfs-utils is not needed to build fedfs-utils-lib Removing that dependency allows the fedfs-utils package to build which in will allow the nfs-utils package to build. Additional info: The reverting of commit c6ed2a61 also removes the circular dependency
A few notes: The actual fix seems to be the removal of the nfs-utils version dependency from the fedfs-utils-lib package. That allows fedfs-utils to build without pulling in nfs-utils. That dependency was there simply to require a version of nfs-utils that has junction support in mountd, but a proper version of nfs-utils is automatically ensured in Fedora. Thus the dependency is likely unnecessary. Re: commit c6ed2a61, It's not clear why -devel needs to depend on -lib. Seems like that dependency could be removed safely. On the other hand, the only thing I've found that pulls in fedfs-utils-lib is fedfs-utils-server. Seems like libnfsjunct.so could be packaged in fedfs-utils-server, and we could drop -lib. Does anyone know if there's a packaging requirement for keeping libnfsjunct.so in it's own little shrink-wrapped box?
(In reply to Chuck Lever from comment #1) > A few notes: > > The actual fix seems to be the removal of the nfs-utils version dependency > from the fedfs-utils-lib package. That allows fedfs-utils to build without > pulling in nfs-utils. > > That dependency was there simply to require a version of nfs-utils that has > junction support in mountd, but a proper version of nfs-utils is > automatically ensured in Fedora. Thus the dependency is likely unnecessary. Yes, it doesn't make sense for a library to require one of it's potential users. I removed the nfs-utils version dependency and re-built the package. That built fine so the compose blocking should be ok now. > > Re: commit c6ed2a61, It's not clear why -devel needs to depend on -lib. > Seems like that dependency could be removed safely. The story is not quite so simple with this. > > On the other hand, the only thing I've found that pulls in fedfs-utils-lib > is fedfs-utils-server. Seems like libnfsjunct.so could be packaged in > fedfs-utils-server, and we could drop -lib. Does anyone know if there's a > packaging requirement for keeping libnfsjunct.so in it's own little > shrink-wrapped box? At the time my impression of the Packaging Policy was something like: - the .so should be in the devel package. - the devel package should not be required by runtime packages. - it was permitted to include the .so in a -lib sub-package (not sure that actually adhered to the packaging requirements). But nfs-utils needs the .so as it does a dlopen() of that name. And so the .so was packaged in a -lib sub-package so it could be used as a dependency by nfs-utils without requiring the -server package, since that isn't needed by nfs-utils either. So I think it's probably best to leave that as it is. I'll wait for any further comments before closing this as CURRENTRELEASE. Ian
(In reply to Ian Kent from comment #2) > (In reply to Chuck Lever from comment #1) > > Re: commit c6ed2a61, It's not clear why -devel needs to depend on -lib. > > Seems like that dependency could be removed safely. > > The story is not quite so simple with this. > > > > > On the other hand, the only thing I've found that pulls in fedfs-utils-lib > > is fedfs-utils-server. Seems like libnfsjunct.so could be packaged in > > fedfs-utils-server, and we could drop -lib. Does anyone know if there's a > > packaging requirement for keeping libnfsjunct.so in it's own little > > shrink-wrapped box? > > At the time my impression of the Packaging Policy was something > like: > - the .so should be in the devel package. > - the devel package should not be required by runtime packages. > - it was permitted to include the .so in a -lib sub-package (not > sure that actually adhered to the packaging requirements). > > But nfs-utils needs the .so as it does a dlopen() of that name. > And so the .so was packaged in a -lib sub-package so it could > be used as a dependency by nfs-utils without requiring the > -server package, since that isn't needed by nfs-utils either. > > So I think it's probably best to leave that as it is. > I'll wait for any further comments before closing this as > CURRENTRELEASE. I didn't remember why we had both subpackages, so thanks for the explanation. The only reason I could think of having a separate -server and -lib was packaging policy. I'm happy with the one-line fix. Would you consider backporting this fix to the other Fedora distributions that are still active (f23 and f22) and to RHEL 7?
(In reply to Chuck Lever from comment #3) > (In reply to Ian Kent from comment #2) > > (In reply to Chuck Lever from comment #1) > > > Re: commit c6ed2a61, It's not clear why -devel needs to depend on -lib. > > > Seems like that dependency could be removed safely. > > > > The story is not quite so simple with this. > > > > > > > > On the other hand, the only thing I've found that pulls in fedfs-utils-lib > > > is fedfs-utils-server. Seems like libnfsjunct.so could be packaged in > > > fedfs-utils-server, and we could drop -lib. Does anyone know if there's a > > > packaging requirement for keeping libnfsjunct.so in it's own little > > > shrink-wrapped box? > > > > At the time my impression of the Packaging Policy was something > > like: > > - the .so should be in the devel package. > > - the devel package should not be required by runtime packages. > > - it was permitted to include the .so in a -lib sub-package (not > > sure that actually adhered to the packaging requirements). > > > > But nfs-utils needs the .so as it does a dlopen() of that name. > > And so the .so was packaged in a -lib sub-package so it could > > be used as a dependency by nfs-utils without requiring the > > -server package, since that isn't needed by nfs-utils either. > > > > So I think it's probably best to leave that as it is. > > I'll wait for any further comments before closing this as > > CURRENTRELEASE. > > I didn't remember why we had both subpackages, so thanks for the > explanation. The only reason I could think of having a separate -server and > -lib was packaging policy. I'm happy with the one-line fix. Great. > > Would you consider backporting this fix to the other Fedora distributions > that are still active (f23 and f22) and to RHEL 7? That is a good idea. I'll do it once I get time, might be a little while though. Ian
fedfs-utils-0.10.5-2.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-b8e2ee28e7
fedfs-utils-0.10.5-2.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2015-ee2aba7db5
fedfs-utils-0.10.5-2.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with $ su -c 'dnf --enablerepo=updates-testing update fedfs-utils' You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-ee2aba7db5
fedfs-utils-0.10.5-2.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with $ su -c 'dnf --enablerepo=updates-testing update fedfs-utils' You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-b8e2ee28e7
fedfs-utils-0.10.5-2.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
fedfs-utils-0.10.5-2.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.