You can't assume that any of your dependencies are available in your postrm script, so you need to handle the case where mktexlsr has already been removed.
The man page of bash tells us, that it should be sufficient to do so
if /bin/sh points to /bin/bash. I guess we have to remove the bashism
in that script and are done. Correct?
Some corrections regarding statements in this bug ("postrm assumes
mktexlsr is available").
<-- snip -->
Ryan Murray:
You can't assume that any of your dependencies are available in
your postrm script, so you need to handle the case where mktexlsr
has already been removed.
mktexlsr is in tetex-bin.
tetex-extra depends on tetex-bin.
Section 7.2. of your policy states:
<-- snip -->
...
The `Depends' field should also be used if the `postinst',
`prerm' or `postrm' scripts require the package to be present in
order to run. Note, however, that the `postrm' cannot rely on
any non-essential packages to be present during the `purge'
phase.
...
<-- snip -->
Could you explain your statement which exactly contradicts your policy
(note that the tetex-extra postinst does nothing during purge)?
Can you reproduce the bug?
If yes, does it help to let /var/lib/dpkg/info/tetex-extra.postrm start
with
#!/bin/bash
?
<-- snip -->
Hilmar Preusse:
The man page of bash tells us, that it should be sufficient to do so
if /bin/sh points to /bin/bash. I guess we have to remove the bashism
in that script and are done. Correct?
If the problem is a bashism, the trivial solution is to let the script
start with
#!/bin/bash
instead of
#!/bin/sh
This is 100% correct since bash is Essential and /bin/bash is therefore garuanteed to be always available.
<-- snip -->
On 11.08.04 Adrian Bunk ([email protected]) wrote:
Hi,
Some corrections regarding statements in this bug ("postrm assumes
mktexlsr is available").
<-- snip -->
Ryan Murray:
You can't assume that any of your dependencies are available in
your postrm script, so you need to handle the case where mktexlsr
has already been removed.
mktexlsr is in tetex-bin.
tetex-extra depends on tetex-bin.
Section 7.2. of your policy states:
<-- snip -->
...
The `Depends' field should also be used if the `postinst',
`prerm' or `postrm' scripts require the package to be present in
order to run. Note, however, that the `postrm' cannot rely on
any non-essential packages to be present during the `purge'
phase.
...
<-- snip -->
Could you explain your statement which exactly contradicts your policy
So, what are you trying to tell me? As far as I understand you tell
me, that this bug is not a bug.
(note that the tetex-extra postinst does nothing during purge)?
mktexlsr is intended to be called in case of upgrade, remove or purge.
Hence we don't check $1, but call it unconditionally.
...
The more convenient solution could be to remove to bashism. Should
not be that hard in this special case. I'm not sure, if command is a
bashism or if it is available in dash too.
...
Thanks,
H.
On Thu, Aug 12, 2004 at 01:44:22PM +0200, Hilmar Preusse wrote:
So, what are you trying to tell me? As far as I understand you
tell me, that this bug is not a bug.
A failed postrm is a bug, but as far as I can see, the problem is
not that mktexlsr wasn't available.
(note that the tetex-extra postinst does nothing during purge)?
mktexlsr is intended to be called in case of upgrade, remove or purge. Hence we don't check $1, but call it unconditionally.
As far as I can see, it's not called during purge.
The more convenient solution could be to remove to bashism.
Should not be that hard in this special case. I'm not sure, if
command is a bashism or if it is available in dash too.
...
It's currently not even 100% clear why the postrm fails.
@Ryan:
Could you reproduce the problem, and if yes, what's the output with
a "set -x" in the postrm script?
On 12.08.04 Adrian Bunk ([email protected]) wrote:
On Thu, Aug 12, 2004 at 01:44:22PM +0200, Hilmar Preusse wrote:
Hi Adrian,
So, what are you trying to tell me? As far as I understand you
tell me, that this bug is not a bug.
A failed postrm is a bug, but as far as I can see, the problem is
not that mktexlsr wasn't available.
Sorry, I have no clue, what exactly he's referring to. I just
thought, it is a general (policy) issue, that we assume some things
to be existent which aren't.
(note that the tetex-extra postinst does nothing during purge)?
mktexlsr is intended to be called in case of upgrade, remove or purge. Hence we don't check $1, but call it unconditionally.
As far as I can see, it's not called during purge.
Maybe I'm dumb. If you do the experiment: Install tetex-base, -bin,
-extra and then purge tetex-extra he'll call mktexlsr. Same happens
on remove.
...
H.
On Fri, Aug 13, 2004 at 06:07:03PM +0200, Hilmar Preusse wrote:
Maybe I'm dumb. If you do the experiment: Install tetex-base, -bin,
-extra and then purge tetex-extra he'll call mktexlsr. Same
happens on remove.
If you purge an installed package, it's first removed and then purged.
mktexlsr is called during the remove phase, but not during the<snip>
purge phase.
Look at the following (with "set -x" in the postrm script):
<-- snip -->
# dpkg --purge tetex-extra
(Reading database ... 136930 files and directories currently installed.) Removing tetex-extra ...
+ PATH=/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11
+ TETEXDIR=
+ TEXMF=
+ TEXCONFIG=/usr/bin/texconfig
+ BLUESKY_UCF=config.ams config.cm config.amz config.cmz
+ command mktexlsr
+ mktexlsr
mktexlsr: Updating /usr/local/lib/texmf/ls-R...
mktexlsr: Updating /var/lib/texmf/ls-R...
mktexlsr: Updating /var/lib/texmf/ls-R-TEXMFMAIN...
mktexlsr: Updating /var/cache/fonts/ls-R...
mktexlsr: Done.
+ '[' xpurge = xremove ']'
...
Hi Adrian,
Maybe I'm dumb. If you do the experiment: Install tetex-base, -bin, -extra and then purge tetex-extra he'll call mktexlsr. Same
happens on remove.
If you purge an installed package, it's first removed and then purged.
I guess that was my failure.
mktexlsr is called during the remove phase, but not during the
purge phase.
Look at the following (with "set -x" in the postrm script):
<-- snip -->
# dpkg --purge tetex-extra<snip>
(Reading database ... 136930 files and directories currently installed.) Removing tetex-extra ...
+ PATH=/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11
+ TETEXDIR=
+ TEXMF=
+ TEXCONFIG=/usr/bin/texconfig
+ BLUESKY_UCF=config.ams config.cm config.amz config.cmz
+ command mktexlsr
+ mktexlsr
mktexlsr: Updating /usr/local/lib/texmf/ls-R...
mktexlsr: Updating /var/lib/texmf/ls-R...
mktexlsr: Updating /var/lib/texmf/ls-R-TEXMFMAIN...
mktexlsr: Updating /var/cache/fonts/ls-R...
mktexlsr: Done.
+ '[' xpurge = xremove ']'
And this is the point, where he starts purging, right?
...
Regards,
Hilmar
On Sat, Aug 14, 2004 at 12:25:49PM +0200, Hilmar Preusse wrote:
+ command mktexlsr
+ mktexlsr
mktexlsr: Updating /usr/local/lib/texmf/ls-R...
mktexlsr: Updating /var/lib/texmf/ls-R...
mktexlsr: Updating /var/lib/texmf/ls-R-TEXMFMAIN...
mktexlsr: Updating /var/cache/fonts/ls-R...
mktexlsr: Done.
+ '[' xpurge = xremove ']'
And this is the point, where he starts purging, right?
...
no.
I'm an idiot.
Ryan is right.
Purging starts after the "Purging configuration files for tetex-extra".
The mktexlsr call is outside of the check whether it's the removal
phase (I've first looked at 2.0.2-9, where it's inside the check).
Yes. We took it out, to make sure it is called during upgrade too.
Might it be a better idea to check if we're upgrading or removing
before we remove the formats and call mktexlsr, instead of checking
if mktexlsr exists.
Patch attached. Frank, is that a good idea?
Patch attached. Frank, is that a good idea?
+if [ x"$1" = "xremove" -o x"$1" = "xupgrade" ]; then
...
+if [ x"$1" = "xremove" ] || [ x"$1" = "xupgrade" ]; then
(and I would even drop the x thingies 'cause I don't think they are of
any use these days...)
Florent
On Mon, Aug 16, 2004 at 12:23:27PM +0200, Florent Rougon wrote:
...
+if [ x"$1" = "xremove" ] || [ x"$1" = "xupgrade" ]; then
(and I would even drop the x thingies 'cause I don't think they are of
any use these days...)
I don't know which shells have problems without them, but if a script is written to be executed by nearly every shell, I'd keep them.
But following this argumentation, shouldn't maintainers simply put a #!/bin/bash at the top of their scripts instead of removing
bash-specific features?
But following this argumentation, shouldn't maintainers simply put a #!/bin/bash at the top of their scripts instead of removing
bash-specific features?
They are free to do so as far as I am concerned. However, two advantages
of sticking to POSIX shell constructs (when it does not lead to ugly contortions) and using /bin/sh are:
- there are POSIX-compliant shells in Debian that are said to be
faster than bash (cf. the package description for dash);
- there are POSIX-compliant shells in Debian that are smaller than
bash and as a consequence, some people using embedded systems would
like to be able to use them exclusively on these systems, where they
could delete bash to save space.
Florent
The shell speed is hardly the major factor in maintainer scripts speed.
bash is essential.
A Debian system without bash is therefore by definition broken.
Making an essential package non-essential is basically impossible.
If an embedded system is that space limited, it would use a small system based on busybox instead of a Debian installation.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 41:58:34 |
| Calls: | 12,109 |
| Files: | 15,006 |
| Messages: | 6,518,416 |