Oh, pity. I was hoping it would be an easy fix.

MATE immediately restarts the panel when it is killed, so running killall mate-panel has the effect of a panel respawn. Maybe you can use that in a pinch while looking for a proper fix.

If you provide more information on how your system is configured, we can compare and hopefully single out the culprit.

Thank you, yeti and fsmithred. Good to know this is just how it is. I thought something in my /etc/apt/apt.conf.d/ or /etc/apt/preferences.d/ was broken.

Then my guess then is that it is either this way by design (for some reason unknown to me) or else it's a minor bug that's only cosmetic.

At any rate, I booted an old Debian 8 partition, downloaded ffmpeg, installed it, and checked the installed version. There are no url escape codes in the version that apt reports being installed. (I guess this is not surprising since apt gets version number from package's /DEBIAN/control file and not from the name of the .deb file.) No harm, no foul.

bruno@thinkpad8:~/Desktop$ apt-get download ffmpeg
Get:1 http://ftp.us.debian.org/debian/ jessie-backports/main ffmpeg amd64 7:3.2.10-1~deb9u1~bpo8+1 [1,535 kB]
Fetched 1,535 kB in 0s (1,537 kB/s)

bruno@thinkpad8:~/Desktop$ ls
ffmpeg_7%3a3.2.10-1~deb9u1~bpo8+1_amd64.deb # note the '%3a'

bruno@thinkpad8:~/Desktop$ sudo gdebi ./ffmpeg_7%3a3.2.10-1~deb9u1~bpo8+1_amd64.deb 
# installation proceeds normally

bruno@thinkpad8:~/Desktop$ apt list --installed ffmpeg
Listing... Done
ffmpeg/jessie-backports,now 7:3.2.10-1~deb9u1~bpo8+1 amd64 [installed] # note the ':'

Sorry for the noise, but when I first noticed this it was completely unexpected.

Yes. If that's really all you want, putting a line like this at the end of /etc/sudoers (preferably by running # EDITOR=nano visudo) will do the trick:

groucho ALL=(root) NOPASSWD: /usr/bin/wine-stable,/usr/bin/winecfg-stable,/usr/bin/linssid

However, being able to use sudo to run any command you want as any user:group you want is much more convenient. For that, put this at the end of sudoers:

groucho ALL=(ALL:ALL) NOPASSWD: ALL

If you prefer to enter your password each time, use PASSWD instead of NOPASSWD.

P.S. If you are truly in the sudo group, the %sudo... line shown in chris2be8's response should allow you to run any command with sudo provided you enter your password. The problem you are having is either because the %sudo... line is missing from sudoers (unlikely) or, more likely, you are not actually part of the sudo group. Type id at the command line to see the groups you are part of. If you are not part of the sudo group, add yourself to it with this command: # usermod -a -G sudo groucho

Thank you, ralph.ronnquist. I'm embarrassed that S0?eudev is in /etc/rcS.d/ (instead of in /etc/rc2.d/) but I didn't know to look there. A careful look at /etc/inittab would have clued me in to the fact that the /etc/rcS.d/ directory exists and its scripts run before those in /etc/rc?.d/.

You really took it to the next level with the information about the pre-pivot start up. In my mind all that is simply "initramfs stage"--the fine details of which I never considered or even heard of before. Thank you very much for such an insightful answer.

A solution: In /etc/init.d/eudev, add this as the last line of the start) section (in my file, this line ends up being line 218):     
ls /run/udev/tmp-rules* && { sleep 5; /lib/udev/udev-finish; } &

That part of /etc/init.d/eudev now looks like this:

# wait for the udevd childs to finish
    log_action_begin_msg "Waiting for /dev to be fully populated"
    if udevadm settle; then
	log_action_end_msg 0
    else
	log_action_end_msg 0 'timeout'
    fi
    ls /run/udev/tmp-rules* && { sleep 5; /lib/udev/udev-finish; } &
    ;;

    stop)

I discovered something: After every boot, /run/udev/tmp-rules--70-persistent-net.rules exists (populated with naming rules for eth0 and wlan0 based on their MAC addresses), even though /etc/udev/rules.d/70-persistent-net.rules never gets created. So the naming rules are generated anew on each boot, but exist only in RAM.

Maybe the timing of things at boot is such that eudev is trying to commit the naming rules to filesystem before the filesystem can be written to?

@w3 obrigado pelo link. Me cadastrei no git.devuan.org e pedi acesso ao wiki devuanbr. Também fiz o upload da minha chave de SSH pública. Ficarei de olho no wiki e contribuirei quando ver oportunidades, do mesmo jeito que contibuo neste fórum (devagar e sempre).

Thank you very much for that, fsmithred. The 70-persistent-net.rules on my refractasnapshot "parent" partition was definitely not a leftover, either, since that partition was a fresh install.

This is a complete mystery to me at this point.

I'm glad I'm not the only one scratching head over this. I don't care about 70-persistent-net.rules per se--after all, everything works and all machines have the old interface names. But I do want to figure out why the file mysteriously stopped being autogenerated.

Ralph: /lib/udev/rules.d/75-persistent-net-generator.rules exists on all my machines, full of nice-looking code. Neither now nor in the past did any of these machines set the net.ifnames kernel boot parameter.

Haha. When I'm after a tidbit like this, I go crazy.

P.S. My MAC spoofing script works by creating /etc/udev/rules.d/75-mac-spoof.rules that looks something like this:

ACTION=="add", SUBSYSTEM=="net", ATTR{address}=="12:34:56:aa:bb:cc", RUN+="/sbin/ip link set dev %k address 12:34:56:dd:ee:ff"

Since eudev is capable of changing MAC addresses, maybe there's a eudev tool that shows original addresses?