just checked the reporting guidelines, guess this should actually be severity "High"

I didn't change this to high severity because it probably works with jack, which is what the dependencies say and what it was built against. Probably going to have to pick one or the other now.

Thank you for reporting, this is indeed a problem and patchage should be edited to require jack1 strictly, or a solution should be sought. The latter scenario is unlikely to prove fruitful as the two are separate implementations, so we will update patchage as needed within a day or two.

Please also make it a good habit to describe the issue in the bug report itself -- don't just link to references (they can and should be cited at the end). See https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines#Including_relevant_information

edit: How about a patchage-jack2? This could be split from within patchage.

If they're incompatible, jack2 should probably not 'provide' jack. Would make setting up the deps simpler.

It seems there is a fix/workaround available for jack2, probably better to update that package as both jack1 and jack2 should be equivalent implementation for the same protocol. See this link: https://github.com/jackaudio/jack2/pull/62
A google search also shows there is discussion in the jack2 team on implementing the metadata api.

Doug, they are not supposed to be incompatible for the most part; users should be able to use jack2 in place of jack1. These incompatibilities are corner cases.

Jelle, thank you, we'll take a look. This looks like a stopgap solution, but we'll have to see if it works well as a backport.

The real issue here is that the actual patchage build system checks for metadata support automatically and there's no flag for disabling it manually.

@schivmester
I'm going to push an 1.0.0-2 release, including a simple fix for disabling metadata support (it would work with both jack and jack2), if you agree.

Wouldn't that also deprive jack1 users of the metadata support through patchage? If not, go ahead if the patch is not too intrusive to the patchage code.

http://drobilla.net/2014/04/09/pretty-names-in-patchage-via-jack-metadata/

@schivmeister
Yep, it would. I thought it wouldn't be a big deal living without pretty names, while jack2 does not support metadata.
The patch I was talking about, just disable metadata forcedly in build system.
Btw, if you think we should provide this feature, your solution is fine. We should split patchage into patchage-jack{1,2} (both provides patchage).

I'll wait for your opinion before proceeding. (sorry for the late)

Speps, you thought right - in that case I agree with you. I'd rather not have to deal with split packages if the intervention is a few lines of modification. I'm skipping a backport as it's a lot of code and room for error. So go ahead with the fix (it's sitting broken at the moment) and then close this, thanks.