Goswin von Brederlow wrote:
> In the past people have suggested adding something to dpkg that allows
> one to schedule a script to be run _once_ at the end of a dpkg
> session. E.g. every tex font package would call:
>
> dpkg-run-once /usr/share/tetex-bin/update-fonts
It'd have to be once, befor
Frank Küster <[EMAIL PROTECTED]> writes:
> Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
>
>> Frank Küster <[EMAIL PROTECTED]> writes:
>>
>>> Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
>>>
Also how would a package inset such a Post-Invoke line into the
conffig? Modifying the conff
Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
> Frank Küster <[EMAIL PROTECTED]> writes:
>
>> Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
>>
>>> Also how would a package inset such a Post-Invoke line into the
>>> conffig? Modifying the conffile would be a policy violation.
>>
>> The package
Frank Küster <[EMAIL PROTECTED]> writes:
> Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
>
>> Also how would a package inset such a Post-Invoke line into the
>> conffig? Modifying the conffile would be a policy violation.
>
> The package that provides the hook to run provides the config entry; t
Op ma, 17-10-2005 te 16:17 +0200, schreef Frank Küster:
> Hi Wouter,
>
> thanks for your answer - did you reply to me instead to the list on
> purpose?
Uh, no -- sorry.
> If you want, you can cite me on the list.
Here goes :)
> Wouter Verhelst <[EMAIL PROTECTED]> wrote:
>
> >> The big problem
Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
> Also how would a package inset such a Post-Invoke line into the
> conffig? Modifying the conffile would be a policy violation.
The package that provides the hook to run provides the config entry; the
packages that need to run the hook touch a file
Frank Küster <[EMAIL PROTECTED]> writes:
> Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
>
>> Anthony DeRobertis <[EMAIL PROTECTED]> writes:
>>
>>> Frank Küster wrote:
>>>
In the particular case, the reason is something else: If the recommended
package B (tetex-bin) is there, it makes
Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
> Anthony DeRobertis <[EMAIL PROTECTED]> writes:
>
>> Frank Küster wrote:
>>
>>> In the particular case, the reason is something else: If the recommended
>>> package B (tetex-bin) is there, it makes sense to run one of its
>>> executables (mktexlsr,
Anthony DeRobertis <[EMAIL PROTECTED]> writes:
> Frank Küster wrote:
>
>> In the particular case, the reason is something else: If the recommended
>> package B (tetex-bin) is there, it makes sense to run one of its
>> executables (mktexlsr, updmap) to register the files of package A (any TeX
>> f
Josselin Mouette <[EMAIL PROTECTED]> wrote:
> Le vendredi 14 octobre 2005 à 22:23 -0400, Anthony DeRobertis a écrit :
>> Frank Küster wrote:
>>
>> > In the particular case, the reason is something else: If the recommended
>> > package B (tetex-bin) is there, it makes sense to run one of its
>> >
Le vendredi 14 octobre 2005 à 22:23 -0400, Anthony DeRobertis a écrit :
> Frank Küster wrote:
>
> > In the particular case, the reason is something else: If the recommended
> > package B (tetex-bin) is there, it makes sense to run one of its
> > executables (mktexlsr, updmap) to register the files
Frank Küster wrote:
> In the particular case, the reason is something else: If the recommended
> package B (tetex-bin) is there, it makes sense to run one of its
> executables (mktexlsr, updmap) to register the files of package A (any TeX
> font package). This is a time-consuming process. Howeve
Ben Armstrong <[EMAIL PROTECTED]> wrote:
> I don't know about an "established" way, but libc6.postinst looks
> interesting:
>
> # Only get the ones that are installed, and configured
> check=$(dpkg -s $check 2> /dev/null | egrep '^Package:|^Status:' | awk '{if
> ($1 ~ /^Package:/) { package=$2 }
also sprach Frank Küster <[EMAIL PROTECTED]> [2005.10.11.2003 +0200]:
> But this file will stay there if the user chooses to keep their changed
> version.
No, then it would be moved to *.dpkg-dist
--
Please do not send copies of list mail to me; I read the list!
.''`. martin f. krafft <[
On Tue, 2005-10-11 at 19:28 +0200, Frank Küster wrote:
> is there an established way to find out in the postinst script of a
> package whether an other package (e.g. one which we Recommend or
> Suggest) is configured?
Assuming your package does something reasonable with this knowledge ...
> Testi
Ben Armstrong <[EMAIL PROTECTED]> wrote:
> On Tue, 2005-10-11 at 19:28 +0200, Frank Küster wrote:
>> is there an established way to find out in the postinst script of a
>> package whether an other package (e.g. one which we Recommend or
>> Suggest) is configured? Testing for file contents can onl
martin f krafft <[EMAIL PROTECTED]> wrote:
> also sprach Frank Küster <[EMAIL PROTECTED]> [2005.10.11.1928 +0200]:
>> is there an established way to find out in the postinst script of a
>> package whether an other package (e.g. one which we Recommend or
>> Suggest) is configured? Testing for file
On Tue, 2005-10-11 at 19:28 +0200, Frank Küster wrote:
> is there an established way to find out in the postinst script of a
> package whether an other package (e.g. one which we Recommend or
> Suggest) is configured? Testing for file contents can only tell whether
> it is unpacked, but that might
also sprach Frank Küster <[EMAIL PROTECTED]> [2005.10.11.1928 +0200]:
> is there an established way to find out in the postinst script of a
> package whether an other package (e.g. one which we Recommend or
> Suggest) is configured? Testing for file contents can only tell whether
> it is unpacked,
Hi,
is there an established way to find out in the postinst script of a
package whether an other package (e.g. one which we Recommend or
Suggest) is configured? Testing for file contents can only tell whether
it is unpacked, but that might not be enough.
If there isn't, are there other people wh
20 matches
Mail list logo
