So the package that shouldn't have existed made it into buster, there's
a ridiculous situation with 3 packages providing essentially the same
functionality with minor differences and no practical way for a user to
figure out which to install, and no movement on fixing this before the
*next* release.
On Thu, Feb 07, 2019 at 03:34:31PM +0000, Thorsten Glaser wrote:
Henrique de Moraes Holschuh dixit:
On Sun, Jan 20, 2019, at 14:05, Thorsten Glaser wrote:
How about starting a sort of transition to the split packages instead?=
Looks like a sensible approach to me.
It’s a bit too “short” before the release, always has been.
My other ideas, both the p-u and the “castling”, rely too
much on that all things involved go smooth.
I’d like to propose a new plan:
* we still intend to do a rng-tools → rng-tools5 transition
for bullseye but leave buster alone
* we’ll just keep rng-tools (5.x) out of testing, and will
later request package removal of src:rng-tools and the
binary package (but (new) only AFTER the buster release)
* I’ll request removal of rng-tools-debian from testing
(and, therefore, buster), but keep it around in sid
until we have a new solution (to not break existing
users)
* said new solution could be to either add all features
needed to rng-tools5 or, well, keeping rng-tools-debian
(the name’s correct as it’s the former Debian maintainer’s
fork of rng-tools, but we can bikeshed that later) around
* whatever we do, we’ll do it way after the buster release
(so we will have had time to discuss it before implementing)
but way before the bullseye release (so it will have had
enough time to cook in testing/sid beforehand)
* in bullseye, we will need to handle migration from
- rng-tools (2.x) [from buster]
- rng-tools (5.x) [from sid]
- rng-tools5 [from buster/sid]
- rng-tools-debian [from sid]
but we don’t need to handle all of them the same way;
details mostly depend on whether we manage to patch
rng-tools5 enough so that we can migrate *all* of them
to *one* destination package, handling all use cases;
the configuration change needs to be in the release
notes of course, but this way, we’ll have actually
enough time to do that
This most likely means that rng-tools5 people (upstream and
packagers) need to consider adding enough rng-tools-debian
functionality (more command line switches, and making them
actually do what they used to do, and an /etc/default/ file).
Is this agreeable? If so, I’ll go ahead requesting removal
of rng-tools-debian from testing, and we’ll have to continue
blocking rng-tools 5 from entering testing.
The downside is that the fixes in rng-tools-debian won’t
make it into rng-tools in buster, and that rng-tools-debian
will be around for a while longer. But I’ve looked at popcon
and *buntu and saw it’s already used by way more people than
the two or three systems I installed it on myself, so we’ll
do best doing a transition plan including it *anyway*, which
won’t get worse if it sticks round for a while.
Sorry for taking ~2 weeks for this answer, I’ve had the cold
(and now caught conference flu at FOSDEM, no rest for me…),
but I believe that even acting 2 weeks ago we would not have
managed in time it *anything* went wrong, and the current
status quo in testing is “good enough” (that is, not a regres‐
sion from stretch) for us to keep for a release longer. If
one step in the transition had failed, we would have been
left without rng-tools in buster at all, which had derailed
any later transition plans and made users even angrier.
bye,
//mirabilos
--
<cnuke> den AGP stecker anfeilen, damit er in den slot aufm 440BX board passt…
oder netzteile, an die man auch den monitor angeschlossen hat und die dann für
ein elektrisch aufgeladenes gehäuse gesorgt haben […] für lacher gut auf jeder
LAN party │ <nvb> damals, als der pizzateig noch auf dem monior "gegangen" ist
