Comment 17 for bug 210112

Ok, I've taken a closer look now.

First off, there is no policy problem: The package itself doesn't do anything that's not coming from an official mirror in the *packaging*. Programs that the package ships do so, but that's perfectly allowed (a webbrowser with javascript also downloads code from somewhere and executes it for example). Likewise a program may also overwrite config files and do other potentially harmful stuff (e.g. dist-upgrader does exactly this, or any other gui to create/modify config files).
Likewise, imho the package can live in universe, as the contents appear to be fully licensed under gpl. (I can download non-free stuff with wget, but still it's in main).

From a packaging perspective, it looks quite good, I've only seen a minor nitpick that I'd put it all in one source package, but even that's not really a problem. But I didn't look too close though (and also didn't do a test-build). Nonetheless, I believe that the packaging is pretty much in a releasable state, or would only have to go through minor fixes.

From looking at the program, however there still might be a blocking issue: I've seen md5sums in there, which generally is a good thing, but might be a problem here: Are these used to verify the driver versions? If so, how would envy in hardy be able to download newer driver versions, once these are released? Alberto, maybe you can shed some light if I saw this correctly?

Points for me to consider
1) it would be used by a great number of people
2) Cesare's words hold some wisdom: stuffing this in at the last moment might not be the best option because of 1).

This currently makes me a little bit unsure and I have a slight tendency to prefer the route via -backports (with a real high priority once intrepid opens).

P.S.: I'm quite aware that envy is actually fixing a bug elsewhere, and that bug is the beast l-r-m, which cannot get backported easily for new drivers. However I don't think it will get fixed there anywhere soon.