On 3/19/11, Ike Devolder wrote:

For me its all the same, you can remove the nvidia-bede package from aur

i'll keep it in my own source tree because the nvidia-all package assumes the kernel version as the running version

most of the time i build for a kernen which is not running at the time

Ike (aka BlackEagle)

I would really like people to hand out more oppinions about this. This is implicating a lot of packages. Det

On 26 March 2011 15:43, Oon-Ee Ng wrote:

...

This is implicating a lot of packages.

       Det

Hmm, didn't see the email from Devolder. Having written the initial nvidia-beta-all package, I can assure you that nvidia-beta-all (and nvidia-all which Det maintains) builds the modules for all installed kernels. uname -r is not used at all, a bit of sed hackery lists down the installed kernels and builds nvidia modules for each of them.

An advantage of the individual nvidia packages I can see, would be that of the ability to offer prebuilt packages for specific AUR kernels (like kernel26-ck and kernel26-pf) in unofficial repos, which is convenient for some people. Otherwise, the -all version is really handy (I, for one, use it).

On Sun, Mar 27, 2011 at 5:28 PM, Det wrote:

On 3/26/11, Oon-Ee Ng wrote:

...

I can assure you that nvidia-beta-all (and nvidia-all which Det maintains) builds the modules for all installed kernels.

I do? I didn't even know that. The "Maintainer: None" phrase was a little confusing to me ^^.

Anyway, I posted an updated PKGBUILD for the maintainer who adopted the package while I was doing it.

  Det

Ah, didn't you maintain it at one point? I remember seeing your name in relation to it. The other time I see your name repeatedly is when flagging my packages out-of-date =). Thanks by the way.

Not to keep bugging your mailboxes but I suppose the only real reasons for keeping all those nvidia-specific-kernel packages in the AUR boils down to these: 1) The user wants to install an Nvidia driver for a non-booted kernel, yet he doesn't want to install the driver for any the other kernels since the rest (or at least 1 of them) use Nouveau or similar. 2) The maintainer wants to show a link to his unofficial repository containing a precompiled version of his package. If these are enough to keep all that nvidia* stuff in the AUR then I don't mind. It'd just be nice, if somebody came up with a PKGBUILD that would ask the user which of the installed kernels he wanted the nvidia driver to be installed to. In addition the package could hold a simple text file listing all the unofficial repositories for using the precompiled packages instead or something ^^. Det

On Fri, Apr 1, 2011 at 1:39 AM, Rémy Oudompheng wrote:

2011/3/31 Det :

...

Not to keep bugging your mailboxes but I suppose the only real reasons for keeping all those nvidia-specific-kernel packages in the AUR boils down to these:

1) The user wants to install an Nvidia driver for a non-booted kernel, yet he doesn't want to install the driver for any the other kernels since the rest (or at least 1 of them) use Nouveau or similar.

2) The maintainer wants to show a link to his unofficial repository containing a precompiled version of his package.

If these are enough to keep all that nvidia* stuff in the AUR then I don't mind. It'd just be nice, if somebody came up with a PKGBUILD that would ask the user which of the installed kernels he wanted the nvidia driver to be installed to. In addition the package could hold a simple text file listing all the unofficial repositories for using the precompiled packages instead or something ^^.

I am absolutely against replacing "reproducible" PKGBUILDs (those which do not generate variables on-the-fly and can be built in clean chroots and installed with predictable results) with "non-reproducible" PKGBUILDs (those which require user interaction, or use backquotes constructs to modify their source array or $pkgver).

For me the latter category of PKGBUILDs are only convenience solutions (that are sometimes created to work around AUR limitations). They are certainly useful, and most of time welcome in the AUR, but will never in my mind replace true PKGBUILDs that correspond to deterministic and well-defined packages.

A package should only be deleted if it is irrevocably broken or if a package exists that provide the same functionality *at the same level of reproducibility and predictability*.

Rémy.

I agree with the concept. However, in your opinion does nvidia-beta-all fall under non-reproducible? It does different things on different machines, but entirely in a non-interactive way. In case you don't want to bother to take a look at the PKGBUILD (I wouldn't), here's the basic thing it does:- 1. grep through files in /boot/ to find installed kernels 2. compile the NVIDIA driver for those kernels It cannot be compiled in a chroot (unless the requisite kernels are available), but it seems to satisfy the rest of your criteria. The discussion may be moot, however, since I just searched through the AUR for nvidia and noticed most of said packages still have maintainers (did not check whether they were out-of-date). No problem, then. I could possibly simply add white/black-listing to the PKGBUILD to cater for those who want nouveau on specific systems (though AFAIK this would require symlinking of libgl...). I hate PKGBUILDs which interactively ask for anything, there should be a sane default non-interactive behaviour, but also simple tweakables.

Thanks for your response Rémy, On Fri, Apr 1, 2011 at 7:54 AM, Rémy Oudompheng wrote:

My definition was not about interactivity but dynamic nature. nvidia-beta-all is dynamic in the sense that it *computes* local variables that influence the resulting package. A reproducible package does as much as it can to hardcode the parameters and options it uses so that each time it is compiled it must produce the same results (this is usually false, because sonames may change and installed package may influence configuration steps).

In other words, I think PKGBUILDs that could be incorportaed in a binary repository as is should not be removed in favour of a PKGBUILD that cannot be used for a binary repository: nvidia-beta-all can't be used for a repository because it can produce totally different packages with the same name, version and pkgrel. It is however a convenient thing to have.

Fair enough.

By the way, I think you should tweak your PKGBUILD so that it correctly sets its $depends array. I don't think nvidia packages really depend on their associated kernels (I mean you can remove the kernels without removing the modules) but it prevents it from being used as is by people who only have kernel26-lts, for example.

Change made, thanks. Original copied from nvidia-beta, I'll inform the maintainer that that should be removed. Only seems obvious once someone has pointed it out (to me) =)