Dependency of GTK+ via pango.
Created attachment 361400 [details, diff] cairo-1.12.16.ebuild.patch
Has this been tested in an overlay by multiple people for a reasonable period of time? And is the multilib team prepared to maintain the fallout from the conversion?
This has been tested by one person (me) for a few days. I can't speak for what the multilib team is prepared to do -- I was just uploading my multilib patches as suggested in bug 488544.
Fair enough. But seeing how multilib messes up other packages I maintain, I am at this point opposed to applying this patch. Let's see this sufficiently tested first and someone stepping up to maintain it.
We mess up, sure but you can't tell that we don't finally clean up our burden, can you? We will handle the fallout, sure.
The changes could be committed under package.mask and be unmasked once there is enough confidence that they don't break anything. But if the committer watches bugzilla/forums/IRC for reports of breakage and can react quickly, I think that p.mask will be unnecessary.
As for the patch itself, please move doc install to multilib_src_install_all(). Then you won't need the 'if' and '${S}' there. Unless maintainer disagrees, you should use 'einstalldocs' (from eutils) rather than inlined dodoc.
(In reply to Michał Górny from comment #5) > We mess up, sure but you can't tell that we don't finally clean up our > burden, can you? We will handle the fallout, sure. I'm sorry, that didn't come out well. I meant that implementing multilib.eclass support introduces more complexity, which leads to more bugs, which means a higher maintenance burden. Personally I'm not convinced it's worth it, but I won't stop you guys. Since cairo is a widely used library, I just want to be cautious. Let's put this in the x11 overlay, or commit a masked version, to be tested for at least a month and through at least one version bump.
Created attachment 361482 [details, diff] cairo-1.12.16.ebuild.patch (re: comment 7) Thanks for the notes, patch updated. I see that multilib-minimal.eclass already includes the equivalent of einstalldocs as part of multilib-minimal_src_install, and indeed if I remove the multilib_src_install_all rule from the ebuild, the doc files still get installed. I'd just drop the install_all rule, but from the context I'm not sure that's intentional -- should the einstalldocs clone have been wrapped in an "if ! declare -f multilib_src_install" test?
(In reply to Andrew Church from comment #9) > Created attachment 361482 [details, diff] [details, diff] > cairo-1.12.16.ebuild.patch > > (re: comment 7) > > Thanks for the notes, patch updated. Sorry, one more. Please remove the find+rm call, and instead put 'prune_libtool_files --all' in multilib_src_install_all(). > I see that multilib-minimal.eclass already includes the equivalent of > einstalldocs as part of multilib-minimal_src_install, and indeed if I remove > the multilib_src_install_all rule from the ebuild, the doc files still get > installed. I'd just drop the install_all rule, but from the context I'm not > sure that's intentional -- should the einstalldocs clone have been wrapped > in an "if ! declare -f multilib_src_install" test? Yes, that's just a default when you don't declare custom multilib_src_install_all().
Created attachment 361484 [details, diff] cairo-1.12.16.ebuild.patch (re: comment 10) > Sorry, one more. Please remove the find+rm call, and instead put > 'prune_libtool_files --all' in multilib_src_install_all(). Done. > Yes, that's just a default when you don't declare custom > multilib_src_install_all(). Hmm, are you sure? If I delete the einstalldocs line (leaving just prune_libtool_files) then the docs still get installed.
Plus there's a circular dependency on DirectFB. I'd go for multilib cairo without DirectFB support for now.
Committed p.masked with explicit request not to unmask in <30 days and <1 vbump :).
Marking 'fixed' to clean up depgraph.
*** Bug 507980 has been marked as a duplicate of this bug. ***
