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).
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
