Re: RFS: emboss-explorer
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Charles Plessy ha scritto:
> Hi David, hi all,
Hi Charles,
>
> ...
>
> 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 ;-)
> In line with this change,
> can you change the maintainer to:
>
> Debian EMBOSS Packaging Team <pkg-emboss-devel@lists.alioth.debian.org>
Done.
> For the dependancies of emboss-explorer, I am unsure wether emboss-help
> is requred. Does emboss-explorer rely on files provided by this package?
> Otherwise, since it is already suggested by emboss itself, it may be
> simpler to drop it.
There's no such dependency. Are you sure you looked at my package? :-)
> A minor point about the description: as the DebTags will already
> indicate that emboss-explorer is made in Perl, maybe you can drop the
> last sentence.
Are DebTags generated automatically? Should I add them somewhere? If yes, how?
> Debian/docs contains only one file. You may opt to add README as an
> argument to dh_installdocs.
Fixed.
> The core of emboss-explorer is mostly a perl module. I am wondering if
> it is worthwile to dedicate him a debian pacakge, with a name such as
> libemboss-perl. I recommend to consult the pkg-perl group to decide what
> and how to do. You may also find useful information in:
> http://www.debian.org/doc/packaging-manuals/perl-policy/ch-module_packages.html
Doesn't it make emboss-explorer too modular? Just IMHO.
> 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.
> Thank you very much for taking time to write nice XML manpages. For the
> next you write, I recommend to use the latest templates, in
> /usr/share/doc/docbook-xsl/examples/
I'll check them, thank you.
> Here is maybe the most imprtant comment: I think that your file layout
> does not respect the policy. The relevant part is 11.5
> (http://www.debian.org/doc/debian-policy/ch-customized-programs.html#s-web-appl)
Trying to fix this. I've had some problems with the package (it's the first
Perl-related package I write, so forgive me ;-) )
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
2. the images issue... I've changed debian/rules so that images are installed
into /usr/share/images/emboss-explorer, and patched debian/install-script so
that Conf.pm looks for images into http://localhost/images/emboss-explorer/*
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 :-)
> Lastly, since EMBOSS is still in experimental, I recommend to upload in
> experimental as well for the moment.
Fixed.
> Also, because of binary name
> conflicts, we will very son move the binary programs of EMBOSS to
> /usr/lib/emboss, which will be the only place where they are guaranteed
> to be unchanged. (/usr/bin will contain symlinks, some of them with
> modified names.) Emboss-explorer will have to take this into account.
> For the moment, its configuration seems to be done through
> EMBOSS::CGI::Conf.pm. Either we can patch new values in it, or we can
> try to make it parse a file in /etc.
Please, take a look at debian/install-script. That's where Conf.pm values are
set. It's just changing some values ;-)
> Let us think about the output files and the cronjobs in a separate
> mail, after the above issues are solved.
Sure.
The package, as it is now, as been uploaded to mentors. Location in the original
post :-)
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.)
> Have a nice day,
You too.
Regards,
David
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.
- --
. ''`. Debian packager! | http://snipurl.com/gofoxygo/
: :' : User #334216 | http://www.hanskalabs.net/
`. `'` GPG: 1392B174 | http://www.debianizzati.org/
`- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGR08d5qqQFxOSsXQRAtfkAKC1lAcPM+bpoVmDSsPLDf7HTT5ssgCfekAm
TLJu1bpD9zo8f03jZUUGOAs=
=oXU/
-----END PGP SIGNATURE-----
Reply to: