Re: policy concerning files used by postinst but not to be installed
The problem is, that if you have postinst delete the files, they are
still registered as belonging to the package. Which is bad, because
they wouldn't exist. Donno if there's a way of unregistering files
(other than parsing /var/lib/dpkg/info/$pkg.list).
The only way to use a file which is not "included in the .deb"
(according to dpkg -L) is to create the file. In this case, by
ungzipping them from their compressed form in /usr/share/$pkg/. So
you still must provide the files "in the .deb". Including them via
./debian/$pkg/tmp/ is bad, because pacakges shouldn't own files in
/tmp. Okay, so there's one exception:
base-files: /tmp
But I think its clear that a database package should not.
I would further argue that users should be able to see what postinst
did after the fact.
Justin
On Fri, Dec 03, 2004 at 04:52:43PM +0100, rixed wrote:
> Frank Küster wrote:
> >You seem to misunderstand me. If you copy the files to
> >debian/tmp/usr/share/..., they will also be included in the deb, and
> >installed on the system - except that you might need to substitute "tmp"
> >for whatever name you use. How else could you use them in postinst?
>
> hu? Ok, I misunderstood. I know I must have those files in the deb, it's
> just that I do not want them installed on the user file system after the
> postinst is over. Like installing them on /tmp, or in another directory
> that postinst would delete after the installation. I was looking for
> something more clean than that. As you spoke about the debian directory
> I thought that it would be a mean to have the files with the deb without
> having them installed (like other files on the debian directory, none of
> them beeing copied definitively on the user file system).
Reply to: