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*/… Maybe I should come up with a toy language that translates 'diversion' to 'courier-mta' as the output of the list is translated. Have you considered that generating the list of diversions could be an IO and/or CPU intensive task? That can be "fixed" by being more careful in the choice of haystack to grep in as well as in refining the needle to search for – or we can take a step back and check if this is an upgrade from a version older than the first one without the diverts and be done with it. This is your choice, you are the maintainer, I am just mentioning things you can look out for in case you haven't so far and want to consider them. And not just you, as this is the mentors list, so I would assume/hope that others read threads on the list and learn from it, which I hope in this thread is "be careful what you grep for"… evil can be everywhere[0]. [0] https://salsa.debian.org/apt-team/apt/-/commit/9bd81ac3c85d8c9fee01d0ecfc681841aa89e6eb > > 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. 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? Best regards David Kalnischkies
signature.asc
Description: PGP signature
