Bug#919893: rng-tools-debian: package shouldn't exist
Hi all, Henrique de Moraes Holschuh dixit: >On Thu, Oct 1, 2020, at 21:05, Michael Stone wrote: >> On Thu, Oct 01, 2020 at 11:20:44PM +, Thorsten Glaser wrote: >> >Michael Stone dixit: >> > >> >> you can fix it right now! >> > >> >So, what do you mean? Take over the rng-tools package? >So, as long as you come up with a proper transition, you are very I now have prepared the transition. For simplicity, I uploaded them keeping the current source to binary package mapping. This way, src:rng-tools can be RM(RoM)’d after the bullseye release. src:rng-tools-debian builds rng-tools-debian 2.2, which contains some of the requested changes, patches from src:rng-tools BTS, etc. and can be coinstalled with rng-tools 5migrate*. src:rng-tools builds rng-tools 5migrate1 which Depends on rng-tools-debian 2.2~ and transitions the old configuration: • the /etc/defaults/ file is migrated to rng-tools-debian unless it was unmodified or empty; there are very few changes between these packages so this is relatively easy • the other three conffiles (init script and two logcheck ignores) are removed if unmodified or empty, put aside otherwise; this means that init script modifications are not retained, but the admin is informed • if transitioning from rng-tools 5-1 (sid), and if the new --hrng=tpm option is used, migration of the configuration is denied because that option does not exist in 2.x (also the TPM is used in a different way); further RNGDOPTIONS changes are not detected, but those who use sid will know anyway • if transitioning from rng-tools 2-unofficial-mt.14-1+b2 (buster) everything is compatible anyway • NEWS.Debian files in both packages explain this, and in addition stress *again* that rng-tools5 probably should be used it possible Now rng-tools-debian again conflicts (well Breaks and Replaces) with rng-tools >= 5migratf (i.e. anything past 5migrate*). This allows us to eventually (in 3 releases or so) rng-tools5 “back” to rng-tools without trouble. The transitional package is oldlibs and contains the magic words “transitional” and “dummy” in the description, so it will most likely be automatically cleaned up. I tested multiple combinations of upgrades from both buster and sid in clean chroots until all I could think of passed. More testing is of course welcome. I uploaded src:rng-tools with urgency=low to allow for some time to test. (The src:rng-tools-debian upload isn’t coupled and can migrate independently.) Thanks for prodding me again, so this can finally be resolved. bye, //mirabilos -- Beware of ritual lest you forget the meaning behind it. yeah but it means if you really care about something, don't ritualise it, or you will lose it. don't fetishise it, don't obsess. or you'll forget why you love it in the first place.
Bug#919893: rng-tools-debian: package shouldn't exist
Hi, >Yes, I have made it clear in the past that I am happy with any >transition plan at all, so I was not under the impression that I had to >write anything... ah okay, and I missed *that*. Great that we talked about it, thanks Michael for pointing us out. >So, feel free to even become the new upstream for the forked codebase! >Or just keep it on deep maintenance as a downstream maintainer, if >you'd rather do it like that. I basically did that already some time ago, so all that’s left is to take over rng-tools for one release and migrate users’ settings. That, and document in the package description and whereever people wish me to do it absolutely clear that this is the “traditional” codebase and they should install rng-tools5 whenever it fits their needs. I’m accepting place and wording suggestions. Thanks, //mirabilos -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt
Bug#919893: rng-tools-debian: package shouldn't exist
Hello... On Thu, Oct 1, 2020, at 21:05, Michael Stone wrote: > On Thu, Oct 01, 2020 at 11:20:44PM +, Thorsten Glaser wrote: > >Michael Stone dixit: > > > >> you can fix it right now! > > > >So, what do you mean? Take over the rng-tools package? > > > >If so, it has a maintainer, you know. hmh has been quiet so far. Yes, I have made it clear in the past that I am happy with any transition plan at all, so I was not under the impression that I had to write anything... So, as long as you come up with a proper transition, you are very welcome to take over the rng-tools name, transition the old, forked codebase for low-bandwidth rng to another name such as rng-tools-legacy or -debian, etc... > he's been clear that he's happy for someone to take it over, or did you > talk to him before uploading your package and he told you that you'd > have to create your own because rng-tools was off limits? I am pretty sure I never hard-rejected any offers to take over the old rng-tools, but if anything I said years ago sounded like it, I can only say it is a major pity it took this long to get it straightened out. So, feel free to even become the new upstream for the forked codebase! Or just keep it on deep maintenance as a downstream maintainer, if you'd rather do it like that. -- Henrique de Moraes Holschuh
Bug#919893: rng-tools-debian: package shouldn't exist
retitle 919893 rng-tools-debian: please take over rng-tools with a proper transition thanks Michael Stone dixit: > On Thu, Oct 01, 2020 at 11:20:44PM +, Thorsten Glaser wrote: >> Michael Stone dixit: >> >>> you can fix it right now! >> >> So, what do you mean? Take over the rng-tools package? >> >> If so, it has a maintainer, you know. hmh has been quiet so far. > > he's been clear that he's happy for someone to take it over, or did you talk > to > him before uploading your package and he told you that you'd have to create > your own because rng-tools was off limits? I’ve not seen that. Please shout loud if this is not okay, otherwise I will proceed doing this. I asked around doing bugreports, which got no reaction, but I don’t remember if I (also) asked hmh directly. Now gimme some time, I’m deep in multiple other things right now. bye, //mirabilos -- “It is inappropriate to require that a time represented as seconds since the Epoch precisely represent the number of seconds between the referenced time and the Epoch.” -- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2
Bug#919893: rng-tools-debian: package shouldn't exist
On Thu, Oct 01, 2020 at 11:20:44PM +, Thorsten Glaser wrote: Michael Stone dixit: you can fix it right now! So, what do you mean? Take over the rng-tools package? If so, it has a maintainer, you know. hmh has been quiet so far. he's been clear that he's happy for someone to take it over, or did you talk to him before uploading your package and he told you that you'd have to create your own because rng-tools was off limits?
Bug#919893: rng-tools-debian: package shouldn't exist
Michael Stone dixit: > you can fix it right now! So, what do you mean? Take over the rng-tools package? If so, it has a maintainer, you know. hmh has been quiet so far. > you keep talking about launchpad, but this is a conversation in debian > channels > about a debian package. what ubuntu did is irrelevant, what matters is the It’s not “what Ubuntu did”. One of the developers suggested this solution to me there, so it was just using Launchpad as communication channel. Please read what was actually written, not just the label. bye, //mirabilos -- 22:20⎜ The crazy that persists in his craziness becomes a master 22:21⎜ And the distance between the craziness and geniality is only measured by the success 18:35⎜ "Psychotics are consistently inconsistent. The essence of sanity is to be inconsistently inconsistent
Bug#919893: rng-tools-debian: package shouldn't exist
On Thu, Oct 01, 2020 at 09:32:47PM +, Thorsten Glaser wrote: Michael Stone dixit: So your position is that rng-tools 2-unofficial-mt.14-1+b2 and rng-tools-debian 2-unofficial-mt.14-3 both in buster are completely different codebases? No, no, no, of course not. I’m talking about sid (and therefore testing). Even before the release of buster, rng-tools in sid was 5 already and therefore unusable. It simply did not migrate in time for buster, thankfully, but the presence of rng-tools-debian would have helped, even so, to alleviate that. It was a botched NMU which happened without discussion. The fix is to overwrite it with a new package. Yes, after both getting a suggestion to do so (via Launchpad) from one of the developers involved *and* running into the problem that rng-tools (in sid) was version 5 and that not getting fixed. you can fix it right now! come up with a better name. rng-tools-legacy makes more sense, or you could It would have made more sense, but we’re past release now, so… you can transition right now! I really don't understand why your attitude has been "I did this thing, I'm not going to change it, and I'm not going to take the remaining steps needed to resolve the mess". rng-tools-debian because you really want to please at least take care of cleaning up the rng-tools transition. I could take over rng-tools and transition them to rng-tools-debian, but this isn’t desired in most cases, so this is really between the maintainers of rng-tools and rng-tools5 in my eyes. there is *no* migration path between rng-tools legacy and rng-tools5. The only transition that makes sense *for debian users* is to consolidate rng-tools and rng-tools-debian. *Of course* the migration that's desired for debian users is to migrate from rng-tools to some other rng-tools legacy package, otherwise people would be running rng-tools5. you keep talking about launchpad, but this is a conversation in debian channels about a debian package. what ubuntu did is irrelevant, what matters is the experience for users of debian (particularly debian stable, for which the situation is as I outlined in the previous mail) The situation in debian unstable is messier *but there is a reason we call it unstable* and it's better to fix the situation for released versions than to worry about unstable users.
Bug#919893: rng-tools-debian: package shouldn't exist
Michael Stone dixit: > So your position is that rng-tools 2-unofficial-mt.14-1+b2 and > rng-tools-debian > 2-unofficial-mt.14-3 both in buster are completely different codebases? No, no, no, of course not. I’m talking about sid (and therefore testing). Even before the release of buster, rng-tools in sid was 5 already and therefore unusable. It simply did not migrate in time for buster, thankfully, but the presence of rng-tools-debian would have helped, even so, to alleviate that. > Then someone decided to NMU rng-tools with a patch to basically make it a copy > of rng-tools5. That never made it to release, and buster was released with > both > rng-tools (legacy) and rng-tools5. It was never reverted. By current migration rules, rng-tools 2.x would even have been removed from testing prior to the release because the then-5.x in unstable did not migrate to testing for long. > And into that you uploaded *another copy* of rng-tools. Yes, after both getting a suggestion to do so (via Launchpad) from one of the developers involved *and* running into the problem that rng-tools (in sid) was version 5 and that not getting fixed. > Ideally you would come up with a transition mechanism to move rng-tools users > to some other package name because you are the one who has laid claim to that > codebase. Upstream expressed an interest of migrating existing users of rng-tools to rng-tools5 if at all possible so the rng-tools5 maintainers are invited to transition like that. > I still believe that rng-tools-debian is a terrible name because it Yes. If these concerns were raised in time, we could have easily renamed it before the buster release. (The package was already in existence for some time because *buntu had the 5 versions much earlier, but I’d have ignored that and dealt with it.) Back then, 5 was the *buntu version and 2 the Debian version, so the naming was somewhat caused from that. > is not sponsored by the debian project and because the name does not give any > hints to users about why they might want to use the package. If anything it I’ve long added this to the package description: This is an unofficial version of rng-tools which has been extensively modified to add multithreading and a lot of new functionality. However, most users of newer or high-bandwidth HWRNGs might wish to install the 5.x version of rng-tools, also packaged as rng-tools5, instead; while it lacks some of the new functionality from this version, it offers more performant support for those. The package is also “native” now, so it’s kinda “the one that contains tons of changes developed during Debian packaging historically”. Let’s take this as naming reason, because changing the name _now_ is going to be more hassle than it is worth and with the package descriptions in both packages adjusted suitably, users will be made aware of it. (Changes to the rng-tools-debian description to express this more clearly and in a more native English language are, of course, very welcome. Just drop me an eMail.) > come up with a better name. rng-tools-legacy makes more sense, or you could It would have made more sense, but we’re past release now, so… > rng-tools-debian because you really want to please at least take care of > cleaning up the rng-tools transition. I could take over rng-tools and transition them to rng-tools-debian, but this isn’t desired in most cases, so this is really between the maintainers of rng-tools and rng-tools5 in my eyes. bye, //mirabilos -- “Having a smoking section in a restaurant is like having a peeing section in a swimming pool.” -- Edward Burr
Bug#919893: rng-tools-debian: package shouldn't exist
On Thu, Oct 01, 2020 at 05:28:12PM +, Thorsten Glaser wrote: Michael Stone dixit: So you could have added whatever you needed to rng-tools and skipped the unnecessary package... No, rng-tools is a completely different software. So your position is that rng-tools 2-unofficial-mt.14-1+b2 and rng-tools-debian 2-unofficial-mt.14-3 both in buster are completely different codebases? Let's review again. Prior to buster there was rng-tools. It's a legacy codebase that's diverged from basically every other distribution. There was also rng-tools5 which was the then-current upstream which provided new functionality and is frankly more useful on modern hardware, but which did not (and probably never will) support the legacy hardware. I had discussed with the (past) rng-tools maintainer the possibility of renaming that to something like rng-tools-legacy with a transition package, with the intent of freeing up the rng-tools package name in the short term and possibly renaming rng-tools5 in the long term. All well and good, stretch was released with rng-tools (legacy) and rng-tools5. Then someone decided to NMU rng-tools with a patch to basically make it a copy of rng-tools5. That never made it to release, and buster was released with both rng-tools (legacy) and rng-tools5. And into that you uploaded *another copy* of rng-tools. So now we have two versions of rng-tools (legacy), one copy of rng-tools5, and a zombie NMU of rng-tools5 called rng-tools in unstable that's been removed from testing so that testing currently has no rng-tools. So anybody using rng-tools in buster will end up with an orphaned package in the next release. There's another version of the same code *but with no transition mechanism* called rng-tools-debian. And there's another package called rng-tools5, originally intended as a bridge to a new package structure, and which is now awkwardly named as the upstream codebase is now up to version 6. Ideally you would come up with a transition mechanism to move rng-tools users to some other package name because you are the one who has laid claim to that codebase. I still believe that rng-tools-debian is a terrible name because it is not sponsored by the debian project and because the name does not give any hints to users about why they might want to use the package. If anything it misleads them into thinking that they should choose the old code if they're running debian when realistically that is almost certainly not the case. As long as transition packages are being discussed it seems like an ideal time to come up with a better name. rng-tools-legacy makes more sense, or you could come up with something better, or if you insist on calling it rng-tools-debian because you really want to please at least take care of cleaning up the rng-tools transition. Once rng-tools in debian stable is migrated to the new package name (with a transition package that goes away) then we'll finally have something sane that supports the users in a reasonable fashion and we'll have a way forward in the future.
Bug#919893: rng-tools-debian: package shouldn't exist
Michael Stone dixit: > No, there were also user confusion, duplication of functionality, and > increased difficulty in future migration. So, the name, and that we have two packages. Oh well, it has happened now. > So you could have added whatever you needed to rng-tools and skipped the > unnecessary package... No, rng-tools is a completely different software. Also, trying to get new features into Debian packages, especially considering this has a different upstream as well, is pretty hard. This step, packaging both, was actually suggested on Launchpad by one of the developers involved. Anyway, it is now here to stay. bye, //mirabilos -- exceptions: a truly awful implementation of quite a nice idea. just about the worst way you could do something like that, afaic. it's like anti-design. that too… may I quote you on that? sure, tho i doubt anyone will listen ;)
Bug#919893: rng-tools-debian: package shouldn't exist
On Thu, Oct 01, 2020 at 04:51:54PM +, Thorsten Glaser wrote: Michael Stone dixit: 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. Yeah well, it exists now, and IIRC the strongest argument against *this* package was the name. No, there were also user confusion, duplication of functionality, and increased difficulty in future migration. But given it’s been in a stable release now, maybe it’s time to retire rng-tools (not rng-tools5), maybe with a transitional package migrating users over to either rng-tools5 or rng-tools-debian, taking their configuration along, or just dropping it so it keeps working for users who have it installed, but new users need to choose one of the others. Incidentally, rng-tools is not in testing but rng-tools5 is, so the maintainer might wish to check whether there’s anything left from the rng-tools package to take over. So you could have added whatever you needed to rng-tools and skipped the unnecessary package... At this point, please just clean up the mess.
Bug#919893: rng-tools-debian: package shouldn't exist
Michael Stone dixit: > 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. Yeah well, it exists now, and IIRC the strongest argument against *this* package was the name. In the meanwhile, the other packages both don’t provide needed functionality, and *this* one has users beyond just me *and* works. It’s also got fixes beyond what was in the others, and, while being low-maintenance, I intend to take care about it. It’s here to stay now. But given it’s been in a stable release now, maybe it’s time to retire rng-tools (not rng-tools5), maybe with a transitional package migrating users over to either rng-tools5 or rng-tools-debian, taking their configuration along, or just dropping it so it keeps working for users who have it installed, but new users need to choose one of the others. Incidentally, rng-tools is not in testing but rng-tools5 is, so the maintainer might wish to check whether there’s anything left from the rng-tools package to take over. bye, //mirabilos -- Beware of ritual lest you forget the meaning behind it. yeah but it means if you really care about something, don't ritualise it, or you will lose it. don't fetishise it, don't obsess. or you'll forget why you love it in the first place.