[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Improve the Val(a)ide package



On Thu, 26 Nov 2009 16:35:27 +0800, Paul Wise <pabs@debian.org> wrote:
> On Thu, Nov 26, 2009 at 5:47 AM, Nicolas Joseph
> <gege2061@redaction-developpez.com> 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:
>>>
>>> http://lintian.debian.org/tags/image-file-in-usr-lib.html
>>
>> If it's a critical warning, I can fix it, but I prefer to have all
files
>> 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
>> file.
>>>
>>> http://lintian.debian.org/tags/extra-license-file.html
>>>
>>
>> Yes the application use the COPYING file for show the license in the
>> about
>> dialog.
> 
> 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
>> usr/lib/libvalide-0.0.so.0.7.0
>>>> usr/lib/libvalide-0.0.so
>>>> 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:
>> cannot
>> 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:
> 
> http://packages.debian.org/sid/amd64/anjuta/filelist
> 

Except the core library /usr/lib/libanjuta.so I have the same
architecture.

> 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:
> 
> http://wiki.debian.org/RpathIssue
> http://lists.debian.org/debian-devel/2002/07/msg02030.html
> 

 - 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
propose it.

Thank's for your help.
-- 
Nicolas Joseph

http://www.valaide.org


Reply to: