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

Re: RFS: emboss-explorer



On Mon, 21 May 2007, Charles Plessy wrote:

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/

This is correct.  All files in the deb package belong to root.  Changes
have to be done after installing the package (i.e. in postinst).

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).

In this case /tmp or /var/tmp might be apropriate as well (this is what
I intende to say that it depends from the application and the taste of
the maintainer which directory to use) which makes changing the permissions
of the directory unnecessary.

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.

Well, I don't know exactly what might be the problem here but I think
dupload might not be the best example for putting an upstream configuration
file into /etc and setting a symlink to this file on the place where upstream
expects its configuration because dupload is a Debian native package and
thus per se expects its configuration in /etc.  But perhaps I missed the
point.  David, make sure you understand my remark about the /etc issue
or ask again if something remains unclear.  I'd happyly explain more
detailed if needed.

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:

You can always do a

     dpkg -S /etc/cron.daily/<your_example_of_choice>

to find out which package installs the file and than look into the
source of this package how it was done.  Your chances are quite good
to find a dh_installcron example this way.

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?

As I said: Have a look into "man dh_install".

Kind regards and thanks for your work on emboss-explorer

            Andreas.

--
http://fam-tille.de

Reply to: