Created attachment 556940 [details, diff] very ugly patch to workaround crypto dependency I don't encrypt disks, so I have 'cryptsetup' disabled however, I'm getting this use conflict: # emerge -avuDN world These are the packages that would be merged, in order: Calculating dependencies... done! The following USE changes are necessary to proceed: (see "package.use" in the portage(5) man page for more details) # required by sys-fs/udisks-2.7.4-r1::gentoo # required by kde-frameworks/solid-5.52.0::gentoo # required by kde-frameworks/kio-5.52.0-r1::gentoo # required by kde-frameworks/kinit-5.52.0::gentoo # required by kde-frameworks/kded-5.52.0::gentoo >=sys-libs/libblockdev-2.14-r1 cryptsetup looking into udisks-2.7.4-r1.ebuild there is: IUSE="acl cryptsetup debug elogind +gptfdisk +introspection lvm nls selinux systemd" ... COMMON_DEPEND=" ... >=sys-libs/libblockdev-2.14[cryptsetup,lvm?] now what sense it makes to have cryptsetup conditional but to have a hard dependency on it? after changing the above line to >=sys-libs/libblockdev-2.14[cryptsetup?,lvm?] and adding a dirty hack, it compiles and runs just fine I know this is upstream issue: https://github.com/storaged-project/udisks/issues/487 however, it seems that a better patch exists (issue #554), so probably you can use it(?) or do something like me but in a cleaner manner (I'm no programmer ...)
No, I don't think it makes sense to carry a patch that upstream does not intend to accept.
(In reply to Mike Gilbert from comment #1) > No, I don't think it makes sense to carry a patch that upstream does not > intend to accept. I'm not sure if we understand each other ... I do not suggest to use my patch - I've appended it a) for the information what dirty hack I'm talking about b) just in case it helps someone (even me in the future when dealing with another installation and hitting this?) to workaround the issue what I am suggesting is to take a look at the patch available at the upstream issue tracker - and there is no indication that the upstream doesn't intend to accept the patch, it's quite the opposite, they are willing to make the change, see tbzatek's reply on #487 the problem is that they do not want to merge it in its current form - so I'd think that letting the patch to mature downstream and eventually improving it would surely help the upstream acceptance I'm not a programmer, so I can't evaluate how far is the current form from the ideal form according to tbzatek's comments, it probably isn't easy, considering that MaxKellermann gave up, but I'd see that as a start ...
(In reply to kavol from comment #2) > the problem is that they do not want to merge it in its current form - so > I'd think that letting the patch to mature downstream and eventually > improving it would surely help the upstream acceptance I think it is more likely that people will lose motivation to push the patch upstream if we apply it downstream. Please work with upstream on this.
(In reply to Mike Gilbert from comment #3) > I think it is more likely that people will lose motivation to push the patch > upstream if we apply it downstream. now I'm confused which people are we talking about ... upstream is on Fedora, which compiles everything in by default, so those developers can't lose the motivation as they never had it in the first place the original submitter MaxKellerman apparently uses Debian, so he would not be affected by this (however it'd be nice to get in touch to test on more distros) and if you had a working patch in Gentoo, then I don't understand what would be the "anti-motivation" to NOT to send it upstream - especially when the current code creates a problem in Gentoo, the 'cryptsetup' use flag conflicts ... I'd think that this would be *your* motivation to have the patch accepted ... probably I should ask the Portage / emerge developers to remove the feature that suggests changes to package.use, which obviously kills your motivation to fix the use conflict properly? :-) > Please work with upstream on this. as said, I'm no programmer, so I can hardly do anything more than kindly asking them to do something about it, and I've already done that I've also talked to Vojtěch Trefný who basically rehashed what tbzatek has replied on the ticket - nice to have, but it needs to be written better and it's too low in priorities (as said above, Fedora doesn't need that ...) so I'm trying to seek help elsewhere, and as said in the previous comment, getting the patch "into the wild" looks to me like a good starting point - and if some (Gentoo) developer can polish that, I don't see how having the patch in Gentoo would block its upstream acceptance
