Re: RFS: emboss-explorer
Hi David!
On 5/13/07, David Paleino <d.paleino@gmail.com> wrote:
> There is a separate Alioth project for EMBOSS, and I added you in. I
> think that it is worthwile to upload emboss-explorer there rather than
> in the debian-med SVN. For the moment it can look like over-engeneering,
> but in the future, both repositories will be big :) Then, could you
> remove emboss-explorer from Debian-Med's SVN?
I don't really know how to do it ;-)
To remove it from Debian-Med's SVN you will use "svn delete" on the
emboss-explorer/ dir and "svn commit". And you have injected it on the
wrong dir! :-)
See http://svn.debian.org/wsvn/debian-med
And then inject it to Emboss repository, like you did before.
> I noticed that the package is Architecture:any. Is there a reason for
> this? Its executables are perl scripts. If you change to Arch:all, I
> thing that you can clean debian/rules from the parts handling gcc
> optimisations.
Is perl the same on every platform?
I've put "any" because I didn't know whether perl worked on each platform or not.
I'm fixing this though.
Yep. Perl scripts are all the same, on all archs. Just the Perl
interpreter that is compiled for a specific arch.
And you can remove ${shlibs:Depends} from the Depends line of debian/control.
1. the cgi-bin issue has been resolved. Now "emboss" (which is the cgi
emboss-explorer uses) is no more in /var/www/cgi-bin, but in /usr/lib/cgi-bin
I didn't see this on your last upload. /var/www/cgi-bin/emboss is
still there and there is an empty dir on the final .deb:
/usr/lib/perl5/
3. the HTML documents issue: I don't know how to solve this.
/usr/share/doc/emboss-explorer is being populated by dh_installdocs, I cannot
just make a link, as I did before. At the moment, in fact, the deb package comes
with a symlink from /usr/share/EMBOSS/doc/html/emboss/apps/ to
/var/www/emboss/manual (the source dir is provided by emboss-doc). How should I
behave now? I can't make a for-loop to look at each file in the source dir,
because emboss-doc might be not installed. The best solution would be to symlink
the source dir to /usr/share/doc/emboss-explorer/ but, again, it's a _real dir_
populated by dh_installdocs. Suggestions are welcome :-)
This part I didn't understand very well :-(
> Lastly, since EMBOSS is still in experimental, I recommend to upload in
> experimental as well for the moment.
Fixed.
debian/changelog still says "unstable" :-)
Btw, the new package (with Architecture: all), gives some lintian "I"s:
I: emboss-explorer source: build-depends-without-arch-dep perl
I: emboss-explorer source: build-depends-without-arch-dep xsltproc
I: emboss-explorer source: build-depends-without-arch-dep docbook-xsl
I: emboss-explorer source: build-depends-without-arch-dep docbook-xml
I: emboss-explorer source: build-depends-without-arch-dep libparse-recdescent-perl
I: emboss-explorer source: build-depends-without-arch-dep libmailtools-perl
Any idea on how to fix these? (ok, they are not errors, but I'd like to have a
lintian-clean package.)
$ lintian -Ii emboss-explorer_2.2.0-1_i386.changes
I: emboss-explorer source: build-depends-without-arch-dep perl
N:
N: The control file lists the given package in Build-Depends, but no
N: architecture-dependent packages are built. If all the packages built
N: are architecture-independent, the only packages that should be listed
N: in Build-Depends are those required to run the clean target (such as
N: debhelper if you use dh_clean). Other build dependencies should be
N: listed in Build-Depends-Indep instead.
N:
N: Refer to Policy Manual, section 7.6 for details.
;-)
You need to add a Build-Depends-Indep: on debian/control and move
perl, xsltproc, docbook-xsl, docbook-xml, libparse-recdescent-perl,
libmailtools-perl from Build-Depends to Build-Depends-Indep, since
they are used to build an arch independent package only.
P.S.: I'll leave for University tonight at 20.30 +0200, so, if I won't answer...
it's because I'm not at home (I don't have connectivity at University). So,
until next weekend, I won't be able to edit the package in any way.
No need to hurry :-)
Best regards,
Nelson
Reply to: