| Summary: | dev-util/android-tools: dev-util/android-udev-rules prevents some devices connecting | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Another Mortal <a.m> |
| Component: | Current packages | Assignee: | Zac Medico <zmedico> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | parona, proxy-maint |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Another Mortal
2022-11-02 20:42:54 UTC
While your solution (removing the dependency or making it optional) might be the path the maintainers decide to take, you've not given enough information for them to fix it any other way. What device of yours wasn't covered by the udev rule? > What device of yours wasn't covered by the udev rule?
I don't see how that matters. There are literally hundreds,
if not thousands of different Android devices out there.
Some will likely not be covered.
Now, given that everything works _without_ these rules,
they seem not only incomplete, but also unnecessary.
(In reply to Another Mortal from comment #2) > > What device of yours wasn't covered by the udev rule? > > I don't see how that matters. There are literally hundreds, > if not thousands of different Android devices out there. > Some will likely not be covered. > It could easily give an example of a property which isn't covered by the existing rules but is sufficient to cover others. My point is, you've assumed the solution rather than letting anyone else think about it first. > It could easily give an example of a property which isn't covered by the existing rules but is sufficient to cover others. Sure... it might, although as I said, my devices connect just fine **WITHOUT** these rules; so, chances are _other_ devices might also do the same. Generally speaking, I'm not at all fond of packages that install _arbitrary_ udev rules in my system. More often than not, they result in breakage. > My point is, you've assumed the solution rather than letting anyone else think about it first. Your point is just plain wrong. I never assumed anything, nor did I prevented others from thinking about alternatives. All I asked was to _consider_ adding a USE flag. I simply suggested my preferred solution. Seeing how these rules are neither useful nor necessary, a USE flag seems like a generally valid approach. That said, everyone is still entitled to think as much as they please. Honestly, I don't particularly care if and how the maintainers choose to fix this, since I've already blocked this package and fixed the ebuild in my local overlay. Yes, it would be more convenient if I didn't have to keep updating my local overlay whenever a new version is released, but I can live with that. That certainly beats having to quarrel about nuances here. The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fd9c418a816f93dcfbe8a4bacf45f472837e51fe commit fd9c418a816f93dcfbe8a4bacf45f472837e51fe Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2022-11-05 23:12:33 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2022-11-05 23:13:04 +0000 dev-util/android-tools: add udev USE flag Closes: https://bugs.gentoo.org/879215 Signed-off-by: Zac Medico <zmedico@gentoo.org> dev-util/android-tools/android-tools-33.0.3-r1.ebuild | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) |
