Re: RFS: emboss-explorer
On Sun, 20 May 2007, Charles Plessy wrote:
Now that EMBOSS::Acd is not in emboss-explorer anymore, you have to
depend on libembnoss-acd-perl. Also, you have to move the manpage from
I smell a tyo here: s/embnoss/emboss/ ...
I tried the packages and on my machine they do not work out of the box.
Apache complains that /var/www/emboss/output is not writeable. Indeeed,
the directory is owned by root and I am unsure that we are allowed to
change this.
Why shouldn't we not be allowed to? We could defintely do make a
chown www-data /var/www/emboss/output
in the postinst script - if this would make sense.
I think that we should better use a more volatile path.
In how far is this path volatile? I don't know the package but your
comments sound a little bit strict.
Maybe /var/run/emboss-explorer?
It depends from the type of the file that should be written. This
path is more about storing status information of programs? What
exactly is the information that has to be written into files written
by emboss-explorer?
There is a similar problem with the configuration: /usr/share/perl5 may
be read-only, or worse: shared between computers. I would suggest to
move the "our" definitions into a file in /etc and source it. This way,
it would also become automatically a conffile. In the current design of
the package, local modifications would be lost at upgrade.
This is right. There are countless exampls how to proceed with
configuration files. Just use a file named for instance
/etc/emboss-explorer.conf or even
/etc/emboss/explorer.conf
and set a symbolic link
ln -a /etc/emboss/explorer.conf /usr/share/perl5/<emboss-explorerdir>/<conffile>
The best idea is to use dh_link (see man dh_link) to do this in your
package. Feel free to ask if somethink remains unclear how to do this.
About the files generated by emboss-explorer, I think that it is our
responsability to chose reasonnable default values and to install a
crontask.
Definitely. See man dh_installcron for the packaging issues.
I have mixed feeling about the install script. If the one provided by
upstream is not patchable, maybe its funcionnalities should be directly
handled by debian/rules and debhelper?
There are several reasons to use or not to use an upstream install script.
In the end the maintainer has to decide what he regards most practical and
ensures that chances are high that upstream version upgrades will happen
flawlessly with his method of packaging. I personally tend to agree with
Charles that if patching the upstream install script is to complecated to
ignore it completely and use debhelper scripts.
- As you said in a previous email, debian/rules is somewhat messy. I
would suggest for instance to either directly install files, or use
dh_install, but not to mix the approaches.
Full agreement here.
- There is a test script in the t directory, maybe we can ship it in
/usr/share/doc/emboss-explorer/examples ?
It is always a good idea to ship examples - man dh_examples is your friend.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: