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,
19 matches
Mail list logo
