Hello Andreas,
On 11/22/12 15:15, Andreas Tille wrote:
Sounds good. I just added gert-guest to the Debian Med project to enable
commit permissions. Note: I also found
Good.
gerddie-guest Gert Wollny
on Alioth - perhaps an old yccount you might have forgot.
Indeed, I didn't remeber that one. First I'll try to recover the
password. The problem is, I don't know which email address I was using.
I doesn't seem to be my current work address.
There is a 1:1 relation between ITP and package. The reason is simple:
If you upload the package the bug is closed - so with the first upload
there would be no remaining bug to close for the other packages.
Okay.
- lintian:
My libmia package contains more than one shared library, so I guess
I should override the "package-name-doesnt-match-sonames", right?
It depends. Alternatively you might consider creating more than one
binary package. It helps to decide if you answer the question whether
it might make any sense to install a single library without all the
others - in this case I'd vote for single binaries. Otherwise a lintian
override might make sense.
You're probably right, the dev package will stay monolithic, but the
libraries (and programs) could be logically divided. I'll thing about
how to do this.
There's another thing I overlooked - MIA uses plug-ins similar to
ocatave using modules *.oct, I decided that it might be better to name
the modules *.mia to avoid that every platform has its own code path for
searching these libs. The problem is, dh_strip doesn't recognice these
files and leaves them unstripped. I've seen this issue discussed with
regard to octave and a bug report regarding Go modules, all unresolved
and quite old. Hence, my solution is to patch the dh_strip script to
consider the *.mia files and include this patched version in the debian
build script, but since my knowledge of perl is close to zero, this is
really a one-time hack. You know of a better solution?
The libmia-doc created by Doxygen contains a "jquery.js"
(embedded-javascript-library). I read that one should add the
according package as dependency and remove the javascript, tried it,
but is seems that the system provided jquery.js is different, i.e.
the documentation web page didn't work properly. So I'd override
this as well.
I recently learned that this could be a dangerous decision. If the
source code contains some compressed JavaScript people do consider
this as "binary without source" which in turn deserves a RC bug (or
ftpmaster will reject the initial upload). Are you really sure that
doxygen created jquery functions are not properly rendered with
Debian's packages jquery?
I just confirmed that it doesn't - the debian package provided version
of jquery is v1.7.1, but the doxygen generated script claims to be
v1.3.2. In addition, I've scanned the doxygen source code, and it
creates different scripts depending on the Doxygen htmlgen options
(doxygen/src/htmlgen.cpp) which leaves the question which of the two
possible versions is provided by debian. Apart from that the Doxygen
tarball distributes the same compressed javascript code (upstream and in
at least in Ubuntu 12.04) as of version 1.8.1.2. I just checked, it
seems that doxygen 1.8.2 (which is in experimental) uses the 1.7.1 jquery.
So in light of being able to backport the package, it would be better to
keep the script, considering the RC bug thingy, I would consider to add
the uncompressed version of the script (if it is still available) to the
source tarball in a contrib directory if doxygen is < 1.8.2, and
otherwise use the package version. Then again there is the danger that
doxygen will not sync to ne new jquery release at the same time debian
provides a new package.
best,
Gert
--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50ae81a0.8030...@gmail.com
