Thank you to everyone here who explained the context of which I was unaware surrounding this issue. I appreciate that you took the time to do that. A couple points in response...

* For the record, if the package maintainer had said in the other ticket, "Yes, the package is broken, but including Selenium Manager in the package is not currently possible because the tools to build it in Debian don't exist and that's not a trivial problem to solve," then we would be having a very different conversation right now, and I would never have escalated this to the technical committee. Instead, what they said was (paraphrasing), "I don't think we should consider the package broken just because it used to work and now suddenly stopped working and the same code that used to work now causes a stack trace, because if the user reads the stack trace and spends about 30 minutes Googling they should be able to figure out how to work around the problem." This is not, in my opinion, a reasonable response. Just because fixing the issue "correctly" involves a lot of work we can't currently do doesn't make that a reasonable response. I realize that adjudicating whether a response from a maintainer is reasonable is outside the purview of the technical committee and I'm not asking for a "ruling" on this one way or another; I just feel compelled to point out that the only reason why I escalated to the technical committee was because the maintainer was not forthcoming.

* I want to push back a bit on the attitude I seem to be hearing here, that people shouldn't report issues unless they're prepared to do the work to fix them, or the corollary, that if no one is currently prepared to do the work to fix an issue then it should just be closed. I don't think people should be rebuffed from reporting real issues just because they don't have the skills or time necessary to fix them themselves, and I think that unresolved or incompletely resolved issues should be kept open until they can be resolved properly.

* Speaking as an end user, I do not agree with the statement, "I see that python3-selenium now has a NEWS.Debian entry that points to README.Debian, which seems like a reasonable way to bring this to users' attention." Most users don't know to look for either of these files. It's simply not going to occur to them that this is a Debian issue requiring special handling; they're simply going to think the package is broken. I could be wrong about this, of course, but this is my gut instinct. Given that the Python code is always going to crash in the same place if it can't find Selenium Manager, then a workaround for this problem would be patch the code so that it catches the exception and points the user at README.Debian before re-raising it.

* If this really is going to be "fixed" just with documentation, then I would argue that the better documentation fix would be to tell the user how they can install Selenium Manager themselves rather than telling them how to hack their code to work around the missing Selenium Manager. That would mean telling amd64 users where to download it, and providing instructions for users on other architectures on how to compile and install it. Heck, maybe even put a shell script in the python3-selenium package that compiles and installs it and just tell the user what it does (full disclosure is important here!) and how to run it.

If there is interest in a combination of the above two changes as an acceptable improved fix for this issue, and someone can point me at where I can get started learning how to submit patches to Debian packages, then I am willing to work on this and submit a patch.

* I agree that patching the Python binding on Debian to restore the previous behavior would be a better short-term fix than what we have now (though I think a combination of the two fixes above would be preferable). However, I'm not sure that's a viable long-term fix, because I imagine that if Selenium Manager "catches on" it will become harder and harder to patch it over time. There's no saying whether I'm right about that or if I am what the time-frame will be, and it could actually go in the opposite direction, i.e., if the maintainers of Selenium get enough push-back about their choice to require their Selenium Manager binary they may reverse that decision.

* Another potential fix for this is to package Webdriver Manager <>, which is essentially a pure-Python replacement for Selenium Manager, make it a dependency of python3-selenium, and patch python3-selenium to use it by default instead of Selenium Manager. I think this would satisfy everyone's concerns, and it would restore python3-selenium to a working state out-of-the-box.

I am also willing to work on this and submit a patch if there is interest in this solution.

* In my opinion, keeping the old version of the Python bindings that didn't require Selenium Manager would have been a better fix than upgrading to a version that doesn't work and requires the user to make platform-specific changes to their code to make it work. Granted, this too is only a short-term fix, so it would only be a stopgap measure until such time as Debian figures out how to build and package Selenium Manager. So this isn't a workable solution if that's unlikely to happen any time soon. If there *is* progress being made on that, and none of the other possible solutions I've enumerated above are considered workable for whatever reason, then I think this one should be considered.


Jonathan Kamens

Reply via email to