13 Sep
2007
13 Sep
'07
1:40 p.m.
2007/9/13, Krzysztof Foltman <wdev(a)foltman.com>om>:
Stefano D'Angelo wrote:
Well... yes. But I don't know if it would work well with a regular
package manager (in terms of packaging work, updates, etc.).
Stefano
I'd say package format (.rpm, .deb, etc), OS
distribution (Ubuntu,
OpenSUSE, etc.), CPU architecture (ix86, x86_64, etc.)
I guess one could think of adding the subarchitecture (as in: p3, p4)
and optimization target too. The difference between subarchitecture and
optimization target would be same as difference between -mcpu and -mtune
gcc options. 
13 Sep
13 Sep
2:36 p.m.
New subject: A common plugin repository (WAS:Re: ladspa qa?)
Stefano D'Angelo wrote:
Well... yes. But I don't know if it would work well with a
regular
package manager (in terms of packaging work, updates, etc.).
You may be right - it would indeed complicate packaging, and the speed
gain is not that spectacular.
Maybe providing the list of optimization options (-O, -mcpu, -mtune,
-ffast-math etc.) as a string would be kind of beneficial (letting the
advanced users know if they want to compile the packages on their own).
Or maybe nobody would use it. I really can't tell.
Krzysztof
I'd say package format (.rpm, .deb, etc), OS
distribution (Ubuntu,
OpenSUSE, etc.), CPU architecture (ix86, x86_64, etc.)
I guess one could think of
adding the subarchitecture (as in: p3, p4)
and optimization target too. The difference between subarchitecture and
optimization target would be same as difference between -mcpu and -mtune
gcc options.
3:04 p.m.
New subject: A common plugin repository (WAS:Re: ladspa qa?)
2007/9/13, Krzysztof Foltman <wdev(a)foltman.com>om>:
Stefano D'Angelo wrote:
Well... yes. But I don't know if it would work well with a
regular
package manager (in terms of packaging work, updates, etc.).
You may be right - it would indeed complicate packaging, and the speed
gain is not that spectacular.
Maybe providing the list of optimization options (-O, -mcpu, -mtune,
-ffast-math etc.) as a string would be kind of beneficial (letting the
advanced users know if they want to compile the packages on their own).
Or maybe nobody would use it. I really can't tell.
Better more information than less... an optimization string looks right to me.
Stefano
I'd say package format (.rpm, .deb, etc), OS
distribution (Ubuntu,
OpenSUSE, etc.), CPU architecture (ix86, x86_64, etc.)
I guess one could think of
adding the subarchitecture (as in: p3, p4)
and optimization target too. The difference between subarchitecture and
optimization target would be same as difference between -mcpu and -mtune
gcc options. 
3:42 p.m.
New subject: A common plugin repository (WAS:Re: ladspa qa?)
IMHO, what's important in the first place is to have a place where one could
found every know plugin.
This let us more time to think about from software discovery and
compatibility/packaging issues.
We may want to look on the side of self contained package. I know this is
not the most clean way we could imagine but we could have some bundle
containing dependencies as well as the plugin. For most of the musician,
this is not a problem to have a bigger plugin package if it just works.
Another better solution, but less generic, is to have a database that maps
plugins to distros package as larsl suggested.
I was originally thinking of having a lib to access the webservice that
would have handled differences between architecture and packaging system
through plugin.
If we mix this with larsl suggestion we have something that is quite generic
and quite clean ?
4:49 p.m.
New subject: A common plugin repository (WAS:Re: ladspa qa?)
2007/9/13, elthariel <elthariel(a)gmail.com>om>:
IMHO, what's important in the first place is to
have a place where one could
found every know plugin.
This let us more time to think about from software discovery and
compatibility/packaging issues.
Yep.
We may want to look on the side of self contained
package. I know this is
not the most clean way we could imagine but we could have some bundle
containing dependencies as well as the plugin. For most of the musician,
this is not a problem to have a bigger plugin package if it just works.
Another better solution, but less generic, is to have a database that maps
plugins to distros package as larsl suggested.
I was originally thinking of having a lib to access the webservice that
would have handled differences between architecture and packaging system
through plugin.
If we mix this with larsl suggestion we have something that is quite generic
and quite clean ?
I would absolutely go this way, given that there are enough
development resources (time, people). Anyway, as I already said
replying to Lars, it is my opinion that the lib (either via these
plugins or not) should access the package management system via
supplied libraries rather than using the package manager executable
whenever possible, so that the application can know more about the
installation process.
Stefano
6310
days inactive
6310
days old
linux-audio-dev@lists.linuxaudio.org
4 comments
3 participants
participants (3)
-
elthariel -
Krzysztof Foltman -
Stefano D'Angelo