On Monday, January 20, 2025 4:35:15 AM MST David Kalnischkies wrote: > 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*/…
I honestly don’t see the problem with this. Even if it does match because some other diversion contains a courier-mta string (which I consider so unlikely as to never happen), all it would do is run two very specific divert removal commands. As the two diversions it is removing should never exist under any other circumstances, no harm is done. It won’t remove any diversion commands that any local admin would have added. > Have you considered that generating the list of diversions could be > an IO and/or CPU intensive task? In my experience it isn’t either IO or CPU intensive, especially compared with all the other things that installing a package entails. >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? The only time any text would be generated is if there is a match, in which case, as you note, other text will also be generated. So, as you say, this script is already silent when there is 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 your comments 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. -- Soren Stoutner so...@debian.org
signature.asc
Description: This is a digitally signed message part.
