Re: Improve the Val(a)ide package
On Thu, 26 Nov 2009 16:35:27 +0800, Paul Wise <email@example.com> wrote:
> On Thu, Nov 26, 2009 at 5:47 AM, Nicolas Joseph
> <firstname.lastname@example.org> wrote:
>>> These should be installed to /usr/share instead. You might need to
>>> patch the source to install them in the right place. See here for why:
>> If it's a critical warning, I can fix it, but I prefer to have all
>> in the same directory.
> Debian prefers FHS compliance
>>>> W: valide-common: extra-license-file usr/share/valide/COPYING
>>> Unless the application needs it, there is no reason to install this
>> Yes the application use the COPYING file for show the license in the
> In that case it is appropriate to override the lintian warning. If it
> is the same as a license in /usr/share/common-licenses then you might
> just want to configure the software to display that instead.
> Alternatively, I think many apps just show the license grant ("This
> program is free software....") in the about dialog and leave the
> license terms for the user to find if they want to.
Fixed in trunk.
>>>> W: valide: non-dev-pkg-with-shlib-symlink
>>>> W: valide: package-name-doesnt-match-sonames libvalide-0.0-0
>>> I imagine these are not meant to be public libraries. If they are
>>> supposed to be private, please work with upstream to make them private
>>> libraries (install in a subdir of /usr/lib). If they are meant to be
>>> public libraries, you need to read libpkg-guide and the bugs filed
>>> against it.
>> This library is used by the core application, if it's not placed in
>> /usr/lib I have the classic error:
>> valide: error while loading shared libraries: libvalide-0.0.so.0:
>> open shared object file: No such file or directory
>> I think that the library is in the good directory (like Anjuta). Is it
>> reasonable to have six packages for this simple application?
> It appears that most of the anjuta libraries are private ones and are
> not located in /usr/lib:
Except the core library /usr/lib/libanjuta.so I have the same
> If no other applications make use of the library, it is a good idea to
> make it a private library. You can do that by placing it in a
> subdirectory of /usr/lib (multi-arch will make this more complex
> though) and using rpath to tell the binary where to find the library.
> Some more info about rpath can be found here:
- The lib is not intended to be used by anyone else. There's no -dev
package for it, it is just a convenience lib to avoid that lots of
related binaries contain the same code.
This point confirm my opignion: I have a -dev package for develop plugins.
I think my package is clean, I will continue to read the DD guide to you
Thank's for your help.