lv2fil

Free Ekanayaka free at 64studio.com
Tue Jul 21 11:44:07 UTC 2009


Hi,

|--==> On Tue, 21 Jul 2009 13:06:11 +0200 (CEST), Jaromír Mikeš <mira.mikes at seznam.cz> said:

  >>Od:  <adi at drcomp.erfurt.thur.de>
  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

So lv2fil doesn't have any architecture-dependent file at all
(e.g. binary executables) but still installs files under /usr/lib/?

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

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

Ciao,

Free



More information about the pkg-multimedia-maintainers mailing list