Bug#702734: [nvidia-detect] please move nvidia-detect out of non-free

[Filipus Klutiero]

Hi Andreas,

On 2013-03-12 04:28, Andreas Beckmann wrote:
> On 2013-03-10 21:53, Filipus Klutiero wrote:
>> nvidia-detect is currently part on non-free, like the rest of
>> nvidia-graphics-drivers. nvidia-graphics-drivers in general is currently
>> non-free, but nvidia-detect in particular has no non-free content.
> for building convenience, see below
>
>> The
>> script has no common license, but I'm offering my contribution under
>> anything wanted.
> Historically the packaging is under GPL2(+), although that may not be
> the optimal choice for a package in non-free, especially wrt. patches.
> Something like BSD/MIT/EXPAT... may be more appropriate. But for your
> script, anything will be fine.
>
> If you send me a Copyright/License header today, I can still include it
> for 304.84 which I'll try to get into wheezy.

I don't mind the license. I'm just saying if we split nvidia-detect, 
we'll have to clarify its license. It doesn't have a clear license 
(which is technically already a small problem) today, but that won't be 
a problem, as I'll happily license it under any terms requested.
>
>> nvidia-detect technically doesn't depend on anything non-free, however
>> it is clearly strongly associated with the non-free rest of
>> nvidia-graphics-drivers, therefore contrib would be a understandable
>> section.
> The main "data" files for nvidia-detect are the PCI ID lists (that are
> automatically generated from upstream's README), so to conveniently
> update nvidia-detect to the latest definitions, I added this package to
> be built from n-g-d. (The lists for the older drivers are copies in
> n-g-d, but they usually don't change frequently, so need no updates).
>
> I don't think the PCI ID lists would make the package non-free.
> Putting it into contrib would be fine, it just needs an extra sync step
> for every new upstream release I wanted to avoid.

So you're saying changing the section requires splitting from n-g-d?

I suspected that splitting the source packages would make updates more 
complicated, although I can't appreciate the cost.
>
>> I would argue main may be the best choice, given that the script could
>> evolve into something a bit greater than a versions advisor. It could
>> certainly recommend using nouveau to vesa users, for example.
> Someone needs to do this ...
>
>> By the way, I recommend to consider making nvidia-detect a source
>> package. This would ease updates after nvidia-graphics-drivers is
>> frozen. It would be best not to leave nvidia-detect untouched in stable
>> for the duration of a whole release cycle.
> Hmm, currently it outputs
>
>    Uh oh. Your card is not supported by any driver version up to 304.64.
>    A newer driver may add support for your card.
>
> for unsupported hardware, and that seems fine for a stable release. We
> will probably have a "more accurate" one in wheezy-backports.
>
>
> Anyway, patches welcome!
>
>
> Andreas

I agree it's "fine". I really meant it would be *better* to keep 
nvidia-detect up-to-date.
I'm not sure a backport for nvidia-detect is the intended use. I see 
backports as appropriate for updates which could introduce breakage. If 
we do ourselves a risk-free update, I think it should go directly in 
stable. But if we keep updates in backports anyway, then we could at 
least prepare stable's nvidia-detect to suggest upgrading to backports 
if the card is unknown (or refer to the wiki's version, or to NVIDIA's 
website).