you may not have seen the announcement below, but the LV2 team has released a meta-package of the LV2 spec.
This basically encompasses all of the LV2 spec 'bundles' into one package, making it much easier to package removing the need to create >15 packages which contain only a directory, header file and TTL file. It also packages what we now package as lv2core. I think this is a great thing - I along with some others pushed for something like this to happen while the adoption of the LV2 spec extensions is still small. Developers up until now have tended to bundle the headers rather than rely on pkg-config.
I propose creating a new package LV2 that obsolotes/provides lv2core (along with the few spec bundles that I have already packaged).
Packaging does not seem to be too much of an issue, in fact using the lv2core spec file as a base, the only real differences (on first looks) are the files section and the obsoletes/provides statement.
%doc COPYING NEWS README
What do you think, is this approach reasonable? We would have to modify all packages that use lv2core (happy to do it). If so, were should we start F16/f17/F18?
-------- Original Message --------
Subject: [LV2] LV2 1.0.0 Released
Date: Wed, 18 Apr 2012 22:40:53 -0400
From: David Robillard <email@example.com>
The first unified LV2 release, LV2 1.0.0, is out.
This release merges the previous lv2core package with all the official
extension packages, as well as example plugins, lv2specgen, and
additional data. From a developer point of view, the biggest change is
that all LV2 API headers can be used by simply checking for the single
pkg-config package "lv2" (for compatibility the previous "lv2core"
package is still installed). Implementations are encouraged to abandon
the "copy paste headers" practice and depend on this package instead.
With this release, several new extensions have become stable that
together greatly increase the power of LV2: atom, log, parameters,
patch, port-groups, port-props, resize-port, state, time, worker.
Documentation and more detailed change logs: http://lv2plug.in/ns/
More information about LV2: http://lv2plug.in/
I would skip F-16 as it is too far into the stable release cycle. For F-17 I am not sure. Does this update require all the dependant plugin and the library packages to be rebuilt and/or modified?
Could we just treat this as a package rename? All the lv2core files are in place.
repoquery --whatrequires lv2core
repoquery --whatrequires lv2core-devel
I just checked lv2.h. There is no API change, at least for Linux. There is some API addition, but nothing to prevent us to push this to stable Fedora.
For the versioned obsoletes/provides, we need to come up with a version greater that 6.0. How about 6.5, that is the revision number in lv2.h?
Would you like to submit a review? I can review if no one else acts before me.
For some reason I was thinking lv2core was 0.6.0 not 6.0. We should probably track upstream version and modify all of the packages above.
It's not a great deal of work, and as you noted lv2core-6.0 is included unchanged . New releases of lilv and suil were also announced yesterday so they will be rebuilt in any case, and lv2-ui would be deprecated by this new package as well.
How about I submit lv2-1.0.0 for review, using obsoletes/provides as appropriate and while I'm waiting to get this review I'll work on updating the plugins and slv2? I'll push into rawhide and then we can make a decision on F17?
Many of the new projects coming out now are starting to embrace the new extensions, so this process should still be quicker than waiting for individual extensions to be packaged and reviewed beforehand.
Indeed, I was once thinking about packaging ingen and friends and then gave up after I realized how much work it would be to package all those lv2 extensions. This will become a convenience for all developers and packagers.
Please submit a review request if/when you get a change, and let me know. lv2core was one of the packages I was planning to hand over this summer, now I can cross it off my list.
Created attachment 578844 [details]
What the new spec may look like
OK, will do.
Attached what the spec may look like. Given the change in version numbering we only need to specify the Obsoletes clause if I have it correctly.
 states that "Examples of packages that should explicitly provide only arch-specific Provides: include native code libraries or plug-ins and their associated -devel packages." I believe lv2core falls in this category. No?
Its arch specific in the sense that its ttl files locations are arch specific, even though there are no binaries, I would have thought that qualified?
Yes, you are right re: arch specific Provides
I guess we need to retire lv2core now. What is the plan?
I want to release the lv2-1.0.0 stack together with suil/lilv etc which now rely on the new upstream tarball.
I'm working through an issue with sratom (new dependency of lilv), so I'm in no hurry to move anything out of rawhide just yet. Should be sorted in the next week or so, one way or the other.
I guess we can start moving on this now - still waiting on resolution to sratom which may result in an update to lv2 but that shan't hold us back.
Should we then proceed to F17 only at this stage? I'm happy with that for the moment - I have had a request to backport into F16 such that the latest jalv/suil/lilv are available, however the previous versions of suil and lilv are already there, so there's nothing stopping us pushing qtractor without the new lv2 stack if need be. The only package to miss out in F16 would then be jalv.
If there are no regressions whatsoever, I am fine with updating F-16+. If we need more testing time to make sure that there are no regressions, then I would say F-17+. Your call.
lv2-1.0.0-6.fc17 has been submitted as an update for Fedora 17.
lv2-1.0.0-6.fc17 has been pushed to the Fedora 17 testing repository.
lv2core is now retired on F-17 and later.
lv2-1.0.0-6.fc17 has been pushed to the Fedora 17 stable repository.