[Devel] Fwd: Re: Thoughts on lv2-universe-YYYYMMDD.tar.bz2

[Brendan Jones]

On 02/11/2012 08:32 PM, David Robillard wrote:
> On Sat, 2012-02-11 at 20:15 +0100, Brendan Jones wrote:
>> On 02/11/2012 07:53 PM, David Robillard wrote:
>>> On Sat, 2012-02-11 at 14:18 +0100, Brendan Jones wrote:
>>> [...]
>>>> I've been thinking about what this means to packaging the LV2 spec in
>>>> general. After some thought I believe Fedora would end up packaging each
>>>> separately in any case, unless all of the spec extensions were versioned
>>>> the same as lv2core, but that would not happen right?
>>>
>>> Right, the actual versions have strong meanings and would remain the
>>> same.
>>>
>>> Why would Fedora still package them individually?  (Debian actually does
>>> it all in one despite them being released individually)
>>>
>>> Would releasing in one tarball make this difficult?  Would each
>>> sub-project having its own build system still be necessary, or would a
>>> single top-level one do?
>>>
>>
>> Well we have some stuff which will only build against lv2core>  4 for
>> example (misplaced header references mainly). I guess if we package the
>> core separately we could do this. But moving forward we still need some
>> way of tracking the version dependencies. Unfortunately there is no
>> facility to attribute different version-release-* tuples within a single
>> RPM in the Fedora build system.

Actually, it is possible to attribute different release numbers for
subpackages, but somewhat frowned upon. Obviously it is less beauracracy
when presented in a single tarball

>
> True, it is nice to have the dependency information exposed at the
> package level.  This is mainly why I was not a fan of what the Debian
> folks did.
>
>> We could version the rest of the spec according to the svn revision /
>> date and prepend the lv2core version e.g. 6.x.svn201202011. The version
>> of the spec package/sub-packages would then only get bumped when the
>> core does. Can you see anything wrong with this approach?
>
> I don't think this is really a solution since there is nothing special
> about core as far as dependencies go.  Something could only build
> against some extension version>  x as well.
>
> Maybe the best way to go would be to simply do both.  Release a big
> tarball for convenience, but everything else stays the same.
> Convenience is the main argument for a single release anyway.

I think so. I see no reason why you shouldn't release the spec as a
single tarball. However, it is unclear why they are released separately
in any case. Why not release all of them together and just bump the
minor release as changes are made to each individual extension? I mean
it is the spec right?
>
> The other was documentation.  The problem is that LV2 documentation
> cross-references between extensions and such.  This could be achieved
> with separate packages as long as packages (or their corresponding doc
> packages) depend on whatever they reference (which they probably should
> anyway) and there is an "LV2 documentation root" directory, which would
> have the same URI-like structure as the includes.  Something like this
> will have to be done for installable plugin documentation as well.
>
That's something that package maintainers can take care of. However when
its not immediately obvious, those doc references (dependancies) should
be noted in the README.

> I am not sure where to make such a directory.  You Fedora folks in
> particular seems to have strong issues with "ownership".  Could, for
> example, lv2core (or lv2core-doc) create /usr/share/doc/lv2 and other
> packages put their documentation in there?

Absolutely. The issue about ownership is more in relation to what
constitutes a development package as opposed to a library/application.
>
> -dr
>