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

Re: RFS: emboss-explorer



Hi all,

David, I assume that your mail has nothing personnal and was intended to
the list, so I answer on the list. As you can see, I am not much more
comfortable than you with web applications, and we definitely need the
support of a mailing list.

Le Sun, May 20, 2007 at 03:40:18PM +0200, David Paleino a écrit :
> 
> > 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. I think that we should better use a more volatile path.
> > Maybe /var/run/emboss-explorer?
> 
> /var/www/* should be owned by www-data (or "nobody", or "apache", or whatever
> user apache runs on), not root, if I remember well.

If other packages do this, I have nothing against. However, as Andreas
said, it need to be done on postinst, otherwise the chown is reverted at
some point:

sorbet【build-area】$ dpkg -c emboss-explorer_2.2.0-1_all.deb | grep output
drwxr-xr-x root/root         0 2007-05-20 18:29 ./var/www/emboss/output/

If I understand correctly, the output directory is more or less a tmp
directory. Once a job is executed, users can download output files, but
they are not given an accession number for retreiving it again (OK: it
justifies why it is in /var/www).

By the way, there are many sites running emboss-explorer, you can try it
here for instance:

http://gump.auburn.edu/srsantos/EMBOSS/


> > 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.
> 
> I've never done a thing like that.

Me neihter :) However, I just remembered this night that dupload uses a
configuration file in Perl. I am sure that you can use it as an example.
I would just suggest to move the variable definitions in a separate file
and to include it with the same mechanisme.


> The default values are already set at the moment. The only remaining thing is
> adding a crontask. What do you suggest? (dh_installcron would help in this case
> - - I've never used it)

It is definitely a good idea. Maybe you can lurk around programs which
install a crontab and see how they are packaged... It seems that cron.d
contains crontabs and cron.daily contains executable files. Also, the
policy is your friend:

http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.5


> I've changed the approach a bit, but I still don't have a "clean" way to install
> things. For instance, how to move files from the top dir into
> debian/<packagename> (or debian/tmp)? The only way I know is using 'install',
> because the <package>.install files are used to build the debs, not to move
> files around. Am I wrong?

I will have a closer look this week... Now it is time for me to go to
work.

Have a nice day,

-- 
Charles Plessy
http://charles.plessy.org
Wako, Saitama, Japan



Reply to: