Hi Helmut, I have a general remark and a technical one.
At 2025-01-08T15:21:42+0100, Helmut Grohne wrote:
> I have bad news about /usr-move. The primary mitigation (M18) for
> aliased diversions (P3) as implemented by me in quite a few packages
> is broken.
[...]
> If your have a lot of time and are interested in the underlying
> technical details, I invite you to continue reading. Otherwise,
> consider doing something more pleasant.
[...]
I'd like to call out this response as salutary example of how to cope
with a setback in project management. Your message is candid, and if
it's not too effusive an utterance, honorable.
There is a saying in management circles, "fix the problem, not the
blame".[1] However, there is another saying, "the officers of the firm
have a legal duty to maximize returns to the shareholders".
The latter is a myth,[2] but an extremely useful fiction for those who
either want to contrive constructive discharge of an otherwise
productive and unobjectionable employee,[3] believe they can derive
greater revenue for the firm, just their department, or simply for
themselves by leaving the problem unfixed--or if someone manages to fix
it anyway on their own damnable initiative, do one's level best to keep
the fix from being widely deployed.[4]
I'll climb off the soapboax and down to technical matters now.
> Fundamentally, I assumed that dpkg-divert --rename would only move a
> file if it was considered installed according to the dpkg database.
> What really happens is that --rename moves a file as long as it
> exists.
Is that within dpkg's specification? If it is, in fact, a bug, should
we consider tackling it for the next development cycle?
If it's valuable behavior nevertheless, should dpkg-divert support an
additional option to force it to operate even on files not installed per
the database? (I assume no one thinks the default shouldn't be to
restrict itself to installed files. Everything I see in the
dpkg-divert(1) man page suggests to me that its only contemplated scope
of application is the set of files actually in a package's payload.)
> Since I was failing to get this right earlier, I figured I could as
> well write some tests.
<applause>
A long time ago I dreaded writing tests. Now, I often get a perverse
satisfaction out of it.
But about as often I get frustrated with the code under test, because I
find out just how under-specified it was. Fantasies of violence
often follow.[5]
At 2025-01-08T15:58:54+0100, Helmut Grohne wrote:
> On Wed, Jan 08, 2025 at 03:21:43PM +0100, Helmut Grohne wrote:
> > write some tests. As a result, I'm attaching a shell script. It
>
> A kind soul reminded me of actually attaching something.
Happens to me (almost) every time...
Regards,
Branden
[1] I tried to trace this quote; the best I can do is to observe that it
was popularized by Michael Crichton in a 1993 novel.
https://www.goodreads.com/work/quotes/2045220-rising-sun
For Crichton personally, a corollary would appear to be "and if
fixing the problem would inconvenience the wealthy people with whom
you rub elbows, deny that the problem exists."
https://www.brookings.edu/articles/michael-crichton-and-global-warming/
Thus can we take a lesson in distinguishing wisdom from the identity
of the oracle uttering it.
[2]
https://www.investopedia.com/terms/s/shareholder-value.asp#toc-what-is-the-shareholder-value-maximization-myth
[3]
https://webapps.dol.gov/elaws/eta/warn/glossary.asp?p=constructive%20discharge
[4] Here's an American computer business story from the 1980s with a
Unix connection.
https://paste.c-net.org/TruthsBottoms
[5] https://en.wikipedia.org/wiki/Rampage_(1986_video_game)
signature.asc
Description: PGP signature
