| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 35 |
| Nodes: | 6 (1 / 5) |
| Uptime: | 18:44:32 |
| Calls: | 321 |
| Calls today: | 1 |
| Files: | 957 |
| Messages: | 82,382 |
to test if the diversion is installed you can probably use
dpkg-divert --list | grep courier-mta
Thanks for the pointer. I have added the following code:
# Delete the old diversions if they exist, which are no longer needed.
# These commands can be removed in trixie +1.
# See <https://github.com/svarshavchik/courier/issues/56>
# See also <https://lists.debian.org/debian-mentors/2025/01/msg00219.html>
if [ dpkg-divert --list | grep courier-mta ]; then
dpkg-divert --package courier-mta --remove --rename \
--divert /usr/bin/addcr.ucspi-tcp /usr/bin/addcr
dpkg-divert --package courier-mta --remove --rename \
--divert /usr/share/man/man1/addcr.ucspi-tcp.1.gz /usr/share/man/man1/addcr.1.gz
fi
Hi,
Am Fri, Jan 17, 2025 at 03:29:39PM -0700, schrieb Soren Stoutner:
to test if the diversion is installed you can probably use
dpkg-divert --list | grep courier-mta
Thanks for the pointer. I have added the following code:
# Delete the old diversions if they exist, which are no longer needed.
# These commands can be removed in trixie +1.
# See <https://github.com/svarshavchik/courier/issues/56>
# See also <https://lists.debian.org/debian-mentors/2025/01/msg00219.html> if [ dpkg-divert --list | grep courier-mta ]; then
dpkg-divert --package courier-mta --remove --rename \
--divert /usr/bin/addcr.ucspi-tcp /usr/bin/addcr
dpkg-divert --package courier-mta --remove --rename \
--divert /usr/share/man/man1/addcr.ucspi-tcp.1.gz
/usr/share/man/man1/addcr.1.gz>
fi
The presented alternative was using a version check. I get it, it looks
a bit more complex and you need to know the version number, but the
benefit of the version check is that it is easy to proof that it runs
once in the upgrade and then never again (if you pick the right number).
By comparison, the grep-based solution is hoping that no translation, no package name and no path name now and up to the point you remove that
code happens to contain the string you grep for.
Sure, "courier-mta" seems like a string unlikely to appear, but can you
be sure?
Random example, but if we ever end up merging /usr/sbin with /usr/bin
and the long tail turns out to be as messy as /bin with /usr/bin
this long forgotten and done with upgrade stanza becomes suddenly very relevant again as courier-mta will once again appear in dpkg-divert.
Best regards
David Kalnischkies
P.S.: Your grep, if it triggers, also generates output on stdout.
At least silence it with -q.
On Saturday, January 18, 2025 8:41:18 AM MST David Kalnischkies wrote:[..]
Am Fri, Jan 17, 2025 at 03:29:39PM -0700, schrieb Soren Stoutner:
if [ dpkg-divert --list | grep courier-mta ]; thenSure, "courier-mta" seems like a string unlikely to appear, but can you
be sure?
P.S.: Your grep, if it triggers, also generates output on stdout.
At least silence it with -q.
Wouldn’t output on stdout be a good thing, especially if there is ever some chance this could run when it shouldn’t.
courier-mta is the package doing the diverting.
P.S.: Your grep, if it triggers, also generates output on stdout.
At least silence it with -q.
Wouldn’t output on stdout be a good thing, especially if there is ever some
chance this could run when it shouldn’t.
Am Sat, Jan 18, 2025 at 11:54:53AM -0700, schrieb Soren Stoutner:
courier-mta is the package doing the diverting.
That is what I meant… you are grepping in a list of ALL diversions by
all packages and everything the local admin has configured. Nothing
defines that the string you match for is not e.g. part of the pathname
in a diversion unrelated to your packaging.
In the random example I fashioned an sbin-merge thingy would introduce a divert on "/usr/sbin/courier-mtaconfig" – notice how that path includes courier-mta and hence matches? (IF it were fashioned after usr-merge the divert would also be created by your package and so be another match ~
so whoever provides the patches will have additional work dealing with
the no longer true assumption that your package has no diverts).
I have no idea about courier-mta AT ALL, but is that the upstream name
of that binary given you seem to rename it in an install rule? If so,
how about a local admin that diverts it to the upstream name for
$reasons. Some people divert example files into non-example locations
and your example file is shipped in /usr/share/doc/*courier-mta*/…
Have you considered that generating the list of diversions could be
an IO and/or CPU intensive task?
The removal of the diversion has dpkg already generate text, so what >additional value does this provide to someone who already has a hard
time finding "interesting" lines in between the upgrade noise?
Can you name another packages maintainer script that does this?
Do you not agree that it would be preferable if maintainer scripts
would be silent if they have nothing of note to report?
I do appreciate you taking the time to comment. Often nobody makes any comments to questions that are asked on the forums, and reading yourcomments
has caused me to think more deeply about dpkg-divert. In this case I personally like the original script because I find it very readable and I don’t feel there are any real concerns with how it functions.
if [[ `dpkg-divert --list courier-mta` ]]; then
One of the advantages of using this check instead of a package version number
is that it can be tested on a machine by manually creating diversions and then
running the script to see if it removes them, which is how I caught the problem.
Am Mon, Jan 20, 2025 at 02:58:21PM -0700, schrieb Soren Stoutner:
if [[ `dpkg-divert --list courier-mta` ]]; then
[[ is a bashism (see checkbashisms from devscripts), so I wonder a bit
how that worked for you in testing and why lintian and co haven't
screamed at you.
You can see the call fail e.g. in piuparts: https://piuparts.debian.org/sid/pass/courier-mta_1.3.13-4.log
| /var/lib/dpkg/info/courier-mta.postinst: 23: [[: not found
(It doesn't fail the script, as using an unknown binary like
this is technically the same as writing `if false; then`)
You can write this line in (da)sh compatible way e.g. so:
| if [ -n "$(dpkg-divert --list courier-mta)" ]; then
(Realising that [ is not syntax but an actual command name
might help in understanding why [[ is not bad syntax either)
One of the advantages of using this check instead of a package version number
is that it can be tested on a machine by manually creating diversions and then running the script to see if it removes them, which is how I caught the problem.
Well, given a version check is done via parameter $2 to the maintainer
script (see d-policy) I suppose testing this is equally hard… as it is mostly about how you call it (did you call it with
bash courier-mta.postinst configure 1.3.13-4
perhaps?) correctly and in the same way it would be called in various situations by dpkg which is the non-trivial part that e.g. piuparts
is supposed to help you with by testing various scenarios.
Removing the preinst is easy so that the diversion doesn’t happen on
new installs, but my question is how to correctly handle the postrm
so that the diversion is removed from current installs on upgrade.
Upgrade is available in preinstall and postinstall [1] so it needs to
be one of the two, not sure which one is better, (maybe preinstall?
but if it fails it goes back the the old version, see dpkg chart)
Upgrade is available in preinstall and postinstall [1] so it needs to be
one of the two, not sure which one is better, (maybe preinstall? but if
it fails it goes back the the old version, see dpkg chart)
I'm not sure, but I would try something like
if [ "$1" = "upgrade" ]; then
#test if the diversion is installed and then remove it
fi
to test if the diversion is installed you can probably use
dpkg-divert --list | grep courier-mta