On Sun, 13 Oct 2024, Sven Geuer wrote: >> like that should look like, and most users will be served with >> rng-tools; rng-tools-debian is for legacy usecases, mostly. > >Unfortunately rng-tools is only a virtual package pulling in rng-tools- >debian. And even worse, autopkgtest installs rng-tools (rng-tools- >debian in the end) when setting up a qemu image [1].
Oh, interesting; I would report that. >There is a rng-tools5 package, however its maintainer looks MIA to me. I meant that package. Bit surprised it’s not (co‑)maintained by hmh. Maybe ask mstone about it, and possibly hmh if he’s interested in picking that up again or something. >Do you now whether rng-tools5 can serve as a drop-in replacement for >rng-tools-debian? Or are you aware of any incompatibilities. I know it’s not a drop-in replacement in general because it lacks most of the command-line options rng-tools-debian accumulated, and even has some of them used for different things. rng-tools 5.x is, however, the supported upstream *and* what other distros (except *buntu, whom I even contacted about the situation but who completely lost this transition) use. And its proponents tell me that it works “by default”, i.e. requiring no special configuration, in more cases. >> You can just start rngd manually, too. (I know I disable the >> initscript on ¾ of my systems.) > >For an autopkgtest VM this is not an option, I am afraid. Ah, so that’s the use case. Does an autopkgtest VM even need it? Wasn’t the collection of entropy from virtio-rng automatic in recent kernels? That being said, the VM I rent from HostEurope has rng-tools-debian pick it up, so maybe not. >> > To me it looks like at least a unit file supporting the same level >> > of functionality like the sysv init script is needed short-term. >> >> *shrug* nothing I could possibly help with. Let me amend that paragraph a bit. Since it’s apparently needed for autopkgtests and stuff, perhaps working together we can do precisely that (same level of support), and I’d argue that the people who argued that it is not the right way had 6+ years and multiple debbugs, some with explicit mentions and RFHs, to respond, and at this point I’m ok with just doing what we already do for sysvinit. I personally cannot write or test systemd anything, I refuse to let the Poettering stuff on my systems. I’ve worked on some other packages where initialisation stuff was shared between systemd stuff and sysvinit, and the seemingly most agreeable way to do that was to put the actual code into a shell script under /usr/lib*/ and to call that from both. (Calling the sysvinit script from the systemd thing, or the other way round, was deemed unpalatable.) So, if I were to move most of the functionality out into a script, will you, or someone else, do the systemd side and test it? (Best before uploading, as we might need a round or two of iterating before deciding on how to exactly call that script.) This is, assuming start-stop-daemon is still fine to use on systemd-using systems. (But the unit generator likely did just that, so it’d be at least no regression.) bye, //mirabilos -- When he found out that the m68k port was in a pretty bad shape, he did not, like many before him, shrug and move on; instead, he took it upon himself to start compiling things, just so he could compile his shell. How's that for dedication. -- Wouter, about my Debian/m68k revival
