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

Re: RFS: presage



On Sun, Jul 11, 2010 at 2:32 AM, Matteo Vescovi
<matteo.vescovi@yahoo.co.uk> wrote:

>> I don't think every package needs to install THANKS, NEWS.gz,
>> README.gz, TODO.gz, AUTHORS since some of them will be automatically
>> installed.
>
> Ok, I removed those files from all packages except for libpresage1 package.

Ah, libpresage1 will be automatically installed so that isn't the best
package for these files.

>> Should the symbols file not be more specific about which symbols are
>> present?
>
> According to the dpkg-gensymbols man page, in section "MAINTAINING
> SYMBOLS FILES", "Using symbol patterns", "symver":
>
> "Well maintained libraries have versioned symbols where each version
> corresponds to the upstream version where the symbol got added. If
> that's the case, you can use a symver pattern to match any symbol
> associated to the specific version."
>
> libpresage now ships a linker version script that versions all
> exported symbols, hence the .symbols file uses the (symver) tag rather
> than duplicating the versioned symbols information defined in the upstream
> libpresage.map linker version script.

Ok, makes sense.

>> What do you think about merging
>> presage/presage-gprompter/presage-pyprompter?
>
> I would rather not do that, for the following reasons:
>
> 1) dependencies
> presage package only depends on libpresage1 (which in turn depends on
> libpresage-data and very few other packages -basically, ncurses and
> sqlite-), whereas gprompter pulls in all the GTK and X dependencies.
> Pyprompter also depends on python-presage package, which in turn pulls in
> all the Python and wxWidget dependencies.
> presage package is meant to only contain the basic tools needed to generate
> language models and resources used by the presage predictive engine.
>
> 2) upstream
> upstream long term plans might include splitting gprompter and pyprompter
> into separate projects. This would allow presage, gprompter, pyprompter to
> be released independently and would cleanly separate the presage predictive
> text engine from applications using it.

Ok, that makes sense.

> Perhaps, in light of 2), it would be better to rename presage-gprompter and
> presage-pyprompter packages to gprompter and pyprompter respectively?

That sounds like a good idea.

>> dpkg-gencontrol: warning: package python-presage: unused substitution
>> variable ${python:Versions}
>
> Not sure where this warning is coming from. The variable is not used
> anywhere in the control file.

That is what the warning is complaining about, that you are missing
${python:Versions} in debian/control. I'd suggest asking on the
debian-python list about it.

>> dpkg-shlibdeps: warning: dependency on libdl.so.2 could be avoided if
>> "debian/libpresage1/usr/lib/libpresage.so.1.1.1" were not uselessly
>> linked against it (they use none of its symbols).
>
> I believe the -ldl flag is being passed in by libtool. It's not explicitly
> passed in by the presage build system. I could track down where this is
> occurring in libtool and patch it. Is this required to get the package
> sponsored?

Nope, just something you might want to look at.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


Reply to: