22 Mar
2012
22 Mar
'12
4:47 a.m.
Hi all,
Pretty strong consensus is that the LV2 specs being a bunch of packages
is a nuisance. So, I plan to start releasing them all in one package.
People have asked for this, but I'm not positive it's what they want.
The main odd consequence would be packages checked by configure scripts
(via pkg-config) will not correlate with tarballs. For example, a
program may check for lv2-state-2.4 but no tarball with that name will
actually exist. It will be in lv2-everything-2012-03-21 or whatever.
It would be difficult to correlate which version of lv2-everything
contains a recent enough version of what you need, if something is
failing to configure.
I don't think it's feasible or wise to mash everything in to one package
right down to the pkg-config level, but I'm open to arguments otherwise.
Extensions are independently versioned so changes to them don't affect
the version of others. In all the ways that count, extensions are
completely decentralized and separate (anyone can make one and
distribute it, or not, on their own), but maybe that doesn't mean they
need to be packaged that way?
In short, I am ready and willing to reshape the packaging to make life
easy and to ease adoption as much as possible, but nobody has come up
with exactly what that is. All suggestions welcome, including blatant
"this is all ridiculous crap and you should just <painfully simple
approach here>" kind of thoughts...
Cheers,
-dr
22 Mar
22 Mar
7:42 p.m.
On 03/22/2012 04:47 AM, David Robillard wrote:
Pretty strong consensus is that the LV2 specs being a
bunch of packages
is a nuisance. So, I plan to start releasing them all in one package.
Good move.
To avoid any confusion about the packages in each release, you could
just accompany each tarball with a manifest that lists the version
information; I guess that this could be generated automatically from the
version numbers in the corresponding manifest.ttl files. And you could
maybe offer a little download page where this information is readily
available in table form so that users and package maintainers can
quickly find the version(s) that they want/need.
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
7:48 p.m.
On Thu, Mar 22, 2012 at 2:42 PM, Albert Graef <Dr.Graef(a)t-online.de> wrote:
To avoid any confusion about the packages in each
release, you could just
accompany each tarball with a manifest that lists the version information; I
guess that this could be generated automatically from the version numbers in
the corresponding manifest.ttl files. And you could maybe offer a little
download page where this information is readily available in table form so
that users and package maintainers can quickly find the version(s) that they
want/need.
or go the git route.
sha-sum the whole thing. the result is the name of the release.
10:27 p.m.
On Thu, 2012-03-22 at 14:48 -0400, Paul Davis wrote:
On Thu, Mar 22, 2012 at 2:42 PM, Albert Graef
<Dr.Graef(a)t-online.de> wrote:
A date is nicer, it sorts. A directory listing of such things would be
a real nightmare.
Note this tarball would just be a distribution for users to build, we
actively don't want packages depending on lv2 everything with one
version number at the source level.
... Well, heck, maybe we actually do. If it's all distributed in one
tarball anyway, there's not much point in checking for every little
piece you use.
There is a certain elegant simplicity in depending on the state of "LV2"
as of YYYY-MM-DD. I am very attached to the decentralized nature of
LV2, but that doesn't mean the actual packaging has to be a shotgun
blast.
The way reality has worked out, stable extensions need to be curated at
lv2plug.in or they tend to rot and confuse people. Perhaps the
extension mechanism should only really be used during the development
process, and we actively *do* want "LV2" to be a collection of
peer-reviewed specs that work nicely together you can grab in one place
and get on with your work.
In other words, perhaps a decentralized specification is a failed idea,
and we don't actually want to encourage independent
extension /publication/. You're still free to actually design and
implement features with no centralized authority, but if you want it to
actually be implemented by others, it should move in to LV2 proper when
it's ready.
It is with reluctance that I admit this, but that seems to be the
conclusion of the experiment.
-dr
To avoid any confusion about the packages in each
release, you could just
accompany each tarball with a manifest that lists the version information; I
guess that this could be generated automatically from the version numbers in
the corresponding manifest.ttl files. And you could maybe offer a little
download page where this information is readily available in table form so
that users and package maintainers can quickly find the version(s) that they
want/need.
or go the git route.
sha-sum the whole thing. the result is the name of the release. 
10:51 p.m.
On 03/22/2012 10:27 PM, David Robillard wrote:
On Thu, 2012-03-22 at 14:48 -0400, Paul Davis wrote:
If it is decided that this the course to take, would it not be better to
attribute a version number to the whole snapshot that meets normal
version numbering conventions rather than a date?
Downstream distros wanting to use a git snapshot can still do so by way
of there package release number. ie 2.x-0.1.git1A2B3CF
On Thu, Mar 22, 2012 at 2:42 PM, Albert
Graef<Dr.Graef(a)t-online.de> wrote:
A date is nicer, it sorts. A directory listing of such things would be
a real nightmare.
Note this tarball would just be a distribution for users to build, we
actively don't want packages depending on lv2 everything with one
version number at the source level.
... Well, heck, maybe we actually do. If it's all distributed in one
tarball anyway, there's not much point in checking for every little
piece you use.
There is a certain elegant simplicity in depending on the state of "LV2"
as of YYYY-MM-DD. I am very attached to the decentralized nature of
LV2, but that doesn't mean the actual packaging has to be a shotgun
blast.
The way reality has worked out, stable extensions need to be curated at
lv2plug.in or they tend to rot and confuse people. Perhaps the
extension mechanism should only really be used during the development
process, and we actively *do* want "LV2" to be a collection of
peer-reviewed specs that work nicely together you can grab in one place
and get on with your work. To avoid any confusion about the packages in each
release, you could just
accompany each tarball with a manifest that lists the version information; I
guess that this could be generated automatically from the version numbers in
the corresponding manifest.ttl files. And you could maybe offer a little
download page where this information is readily available in table form so
that users and package maintainers can quickly find the version(s) that they
want/need.
or go the git route.
sha-sum the whole thing. the result is the name of the release.
In other words, perhaps a decentralized specification is a failed idea,
and we don't actually want to encourage independent
extension /publication/. You're still free to actually design and
implement features with no centralized authority, but if you want it to
actually be implemented by others, it should move in to LV2 proper when
it's ready.
It is with reluctance that I admit this, but that seems to be the
conclusion of the experiment.
-dr
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
10:57 p.m.
On Thu, 2012-03-22 at 22:51 +0100, Brendan Jones wrote:
Well, I don't know about that. Each interface is still a completely
separate thing, and the version numbers for them are maintained
accordingly.
It seems important that a version bump in, say, the state extension,
doesn't mean anything in the core has changed. Paticularly for
developers that don't use state. However, perhaps this argument is
invalid since LV2 specifications never break (their URI must change if
they do, there is no major version).
That's a pretty dramatic change, but it is simpler... a lot simpler...
having all the NEWS files and everything merged, I don't know ...
-dr
On 03/22/2012 10:27 PM, David Robillard wrote:
[...]
The way
reality has worked out, stable extensions need to be curated at
lv2plug.in or they tend to rot and confuse people. Perhaps the
extension mechanism should only really be used during the development
process, and we actively *do* want "LV2" to be a collection of
peer-reviewed specs that work nicely together you can grab in one place
and get on with your work.
If it is decided that this the course to take, would it not be better to
attribute a version number to the whole snapshot that meets normal
version numbering conventions rather than a date? 
11:15 p.m.
I like the idea of an overall version number, so, LV2 V2.1 is released
which contains foo v0.7, ba v1.1, thing v0.4.
Over time foo is updated to v0.8, LV2 V2.2 gets released.
Any client/host using LV2 can then claim a version compatibility, ie
V2.1, but not V2.2.
Seems the most understandable approach to me, in my layman's terms.
Cheers
Chris
On 22/03/12 21:56, David Robillard wrote:
On Thu, 2012-03-22 at 22:51 +0100, Brendan Jones
wrote:
Well, I don't know about
that. Each interface is still a completely
separate thing, and the version numbers for them are maintained
accordingly.
It seems important that a version bump in, say, the state extension,
doesn't mean anything in the core has changed. Paticularly for
developers that don't use state. However, perhaps this argument is
invalid since LV2 specifications never break (their URI must change if
they do, there is no major version).
That's a pretty dramatic change, but it is simpler... a lot simpler...
having all the NEWS files and everything merged, I don't know ...
-dr
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
On 03/22/2012 10:27 PM, David Robillard wrote:
[...]
The way
reality has worked out, stable extensions need to be curated at
lv2plug.in or they tend to rot and confuse people. Perhaps the
extension mechanism should only really be used during the development
process, and we actively *do* want "LV2" to be a collection of
peer-reviewed specs that work nicely together you can grab in one place
and get on with your work.
If it is decided that this the course to take, would it
not be better to
attribute a version number to the whole snapshot that meets normal
version numbering conventions rather than a date?
27 Mar
27 Mar
4:13 a.m.
On Thu, 2012-03-22 at 22:15 +0000, Chris Goddard wrote:
I like the idea of an overall version number, so, LV2
V2.1 is released
which contains foo v0.7, ba v1.1, thing v0.4.
Over time foo is updated to v0.8, LV2 V2.2 gets released.
Done. With respect to pkg-config, the "lv2core" package will remain,
for compatibility. Otherwise, there is just an "lv2" package.
Configure scripts can just check whatever version of that.
Generally, APIs should have meaningful version numbers, but I can't come
up with a scheme for this. People seem to not like the date thing,
though, so "lv2" currently has the completely arbitrary version
"0.1.0".
I guess I will just increment whichever digit I arbitrarily feel like
incrementing that day...
Developers currently following the bleeding edge should dump all their
extension specific pkg-config checks and simply check for 'lv2'. The
price of this change is minimal sympathy for stagnant crap: the
benevolent dictator model will indeed keep things more agile and
unified, but only if you keep up.
-dr
22 Mar
22 Mar
11:18 p.m.
On Thu, Mar 22, 2012 at 05:27:14PM -0400, David Robillard wrote:
In other words, perhaps a decentralized specification
is a failed idea,
and we don't actually want to encourage independent
extension /publication/. You're still free to actually design and
implement features with no centralized authority, but if you want it to
actually be implemented by others, it should move in to LV2 proper when
it's ready.
It is with reluctance that I admit this, but that seems to be the
conclusion of the experiment.
Found this in my spam folder some days ago:
Loony Vacations 2 - The next generation Holiday experience.
We at Loony Vacations 2 offer a unique holiday formula.
When you become a member of our customer society, you can
book a trip to any of our holiday resorts, and stay there
for as long as you care. And what's more, you only pay once,
and only for the Experiences you want. All our resorts provide
basic accomodation - a dorm with bunk beds. Everything else
you want you specify in the list of Experiences for which you
are prepared to pay. Actually, when you book a trip to any
of our resorts, there is no guarantee that all the Experiences
you want will be available there, and you only know when you
arrive. That should not spoil your holiday, just make the best
of it. We have no control over the resort owners, they offer
what they are best at. Also, some Experiences may be change
over time. For example the 'Italian Wines' Experience was not
very popular, and therefore it was recently replaced by the
'Belgian Beers' one - offering our customers who like wines
an unique opportunity to discover something new. Of course,
you can always build your own resort, with all the Experiences
you like, and we will be happy to add it to our offer. Also,
we don't discriminate against any of our clients. Your fellow
holiday makers may be hooligans that stay drunk all day and
keep you awake at night. That's not really a problem, we try
to be a happy community anyway. We are looking forward to take
care of your next holiday !
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
22 Mar
22 Mar
11:47 p.m.
On 03/22/2012 10:27 PM, David Robillard wrote:
Note this tarball would just be a distribution for
users to build, we
actively don't want packages depending on lv2 everything with one
version number at the source level.
If the tarballs are out there, you can't keep the package maintainers
from using them anyway. :)
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
23 Mar
23 Mar
12:44 a.m.
On Thu, 2012-03-22 at 23:47 +0100, Albert Graef wrote:
On 03/22/2012 10:27 PM, David Robillard wrote:
I don't plan on releasing in multiple ways. Whatever The Way(TM) is,
that is the way. If people want one, it's *just* one. Maintaining this
stuff is enough effort when it only needs releasing in one way.
I guess the question isn't so much tarballs, but whether there should be
a build script in each. I guess not, if we're doing the all in one
thing, and encouraging that all the way through to the package manager.
Programs and documentation should be packaged separately though. Since
most build systems that build docs do it all in one go, I assume
packagers are already accustomed to piecing up things that are installed
in one command by the source build system?
-dr
Note this tarball would just be a distribution
for users to build, we
actively don't want packages depending on lv2 everything with one
version number at the source level.
If the tarballs are out there, you can't keep the package maintainers
from using them anyway. :)
8:08 a.m.
On 03/23/2012 12:44 AM, David Robillard wrote:
I don't plan on releasing in multiple ways.
Whatever The Way(TM) is,
that is the way. If people want one, it's *just* one. Maintaining this
stuff is enough effort when it only needs releasing in one way.
Sounds fair.
Programs and documentation should be packaged
separately though. Since
most build systems that build docs do it all in one go, I assume
packagers are already accustomed to piecing up things that are installed
in one command by the source build system?
Yes. At least that's the way it is on the distros I know. This depends
on the distro's packaging policies, though. In any case, I'd say that's
something you can just leave up to the downstream maintainers.
Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
22 Mar
22 Mar
10:12 p.m.
On Thu, 2012-03-22 at 19:42 +0100, Albert Graef wrote:
On 03/22/2012 04:47 AM, David Robillard wrote:
I suppose this would do well enough to resolve the "what version do I
need?" problem. Auto-generation of whatever from the data is naturally
easy with LV2 anyway.
Thanks,
-dr
Pretty strong consensus is that the LV2 specs
being a bunch of packages
is a nuisance. So, I plan to start releasing them all in one package.
Good move.
To avoid any confusion about the packages in each release, you could
just accompany each tarball with a manifest that lists the version
information; I guess that this could be generated automatically from the
version numbers in the corresponding manifest.ttl files. And you could
maybe offer a little download page where this information is readily
available in table form so that users and package maintainers can
quickly find the version(s) that they want/need.
4407
days inactive
4412
days old
linux-audio-dev@lists.linuxaudio.org
13 comments
6 participants
participants (6)
-
Albert Graef -
Brendan Jones -
Chris Goddard -
David Robillard -
Fons Adriaensen -
Paul Davis