Re: Re: lv2fil

Jaromír Mikeš mira.mikes at seznam.cz
Tue Jul 21 12:54:20 UTC 2009


> Od: Free Ekanayaka <free at 64studio.com>

Hi,

JM> > W: lv2fil source: dh-make-template-in-source debian/manpage.1.ex
JM> > Should I write man pages even there is no binary and it is not library?
AK> Not sure. If this would be BSD, there would be a manpage for it. ;)

AK> I suggest to use a very generic one, like: "This is a filter, it has
AK> four bands, and upstream url is..."
 
JM> > W: lv2fil: image-file-in-usr-lib usr/lib/lv2/filter.lv2/lv2logo.png
JM> > http://lintian.debian.org/tags/image-file-in-usr-lib.html
 
AK> Not sure about this one. Is there something like --share-dir? As far as
AK> I know LV2 (and that's close to nothing), the idea is to have all the
AK> files in one directory.

JM> > W: lv2fil: script-not-executable ./usr/lib/lv2/filter.lv2/ui
JM> > http://lintian.debian.org/tags/script-not-executable.html
 
JM> > These issues happened also if I've installed manually from source.
JM> > Should I try to solve them in packaging process or should I ask upstream? 
  
AK> The logo issue could be discussed with upstream. Since ui is a python
AK> script, it would be possible to dynamically change the location upon
AK> invocation or write it at compile time.
  
AK> On the other hand, this might ruin the whole LV2 idea. From lv2plug.in:
 
AK> --- cut ---   
AK> Bundles
  
AK> Everything a LV2 plugin needs is bundled inside a directory, which can
AK> easily be handled as a whole while still allowing direct access to the
AK> parts.
  
AK> --- cut ---
 
AK> This would mean "lintian override". (probably for both warnings) ;)
 
JM> Hi Adrian,
 
JM> thanks for feedback and testing.
JM> There is probably needed a discussion, there will be hopefully some other  lv2 packages soon.
JM> We should know how to deal with these issues.
 
JM> Free? Reinhard? others?
JM> thanks for comments
 
FE> So lv2fil doesn't have any architecture-dependent file at all
FE> (e.g. binary executables) but still installs files under /usr/lib/?

Actually there should be probably one executable file ..."ui"
ui file is executable in source, but after instalation is not executable ... lintian complain coz of it.
It happen also when I install manually.

FE> Ideally /usr/lib should have architecture-independent files in it, as
FE> those should go to /usr/share. However given that the LV2 architecture
FE> explicitly mentions that a plugin should entirely reside in a
FE> directory, my opinion is that it's acceptable to install everything
FE> under /usr/lib/lv2 and add lintian overrides as needed.

By default this plugin installation ask for LV2_PATH environment variable and wants install there.
I am building package in pbuilder there is not LV2_PATH set , so I set installation dir to /usr/lib/lv2 in debian/rules.

Quote from http://lv2plug.in/docs/index.php?title=Loading_Plugins
----
If LV2_PATH is not defined, a good default value (on UNIX systems) is "$HOME/.lv2:/usr/local/lib/lv2:/usr/lib/lv2" (with $HOME replaced by the content of the environment variable HOME). 
----

FE> I say this assuming that most upstream plugins will behave that way by
FE> default, with the all-in-one-dir bundle concept. If this is not the
FE> case and most of them actually allow more flexible installation paths
FE> (like the mentioned --share-dir option), then we should probably try
FE> to make lv2fil more flexible as well.

Here is needed some investigation.

BTW: How will be LV2_PATH set on system? Manually? By installation of some package? lv2core, slv2?

mira



More information about the pkg-multimedia-maintainers mailing list