[aur-general] Should nvidia(-beta)-all replace all the other nvidia-* packages in the AUR?
Helloooo, So I've been thinking about this for some time now and I finally decided to ask the ones who know the best: would it be enough to only have 'nvidia-beta-all' and 'nvidia-all' in the AUR to replace all those nvidia-ice, nvidia-bfs, eg. packages? (Decluding nvidia-utils*, of course.) As far as I can think of, I can't see any downside(s) (whatsoever) of using those *-all packages instead of those 'specifc-kernel' packages, since they do in fact auto-detect all the kernels on the system. Now to the important part: what do you think? Det
Op zaterdag 19 maart 2011 19:19:41 schreef Det:
Helloooo,
So I've been thinking about this for some time now and I finally decided to ask the ones who know the best: would it be enough to only have 'nvidia-beta-all' and 'nvidia-all' in the AUR to replace all those nvidia-ice, nvidia-bfs, eg. packages? (Decluding nvidia-utils*, of course.)
As far as I can think of, I can't see any downside(s) (whatsoever) of using those *-all packages instead of those 'specifc-kernel' packages, since they do in fact auto-detect all the kernels on the system.
Now to the important part: what do you think?
Det
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)
On 3/19/11, Ike Devolder <ike.devolder@gmail.com> 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 Sat, Mar 26, 2011 at 9:15 PM, Det <nimetonmaili@gmail.com> wrote:
On 3/19/11, Ike Devolder <ike.devolder@gmail.com> 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
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.
On 26 March 2011 15:43, Oon-Ee Ng <ngoonee.talk@gmail.com> 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 3/26/11, Oon-Ee Ng <ngoonee.talk@gmail.com> 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
On Sun, Mar 27, 2011 at 5:28 PM, Det <nimetonmaili@gmail.com> wrote:
On 3/26/11, Oon-Ee Ng <ngoonee.talk@gmail.com> 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.
On Saturday, March 19, 2011 20:19:41 Det wrote:
Helloooo,
So I've been thinking about this for some time now and I finally decided to ask the ones who know the best: would it be enough to only have 'nvidia-beta-all' and 'nvidia-all' in the AUR to replace all those nvidia-ice, nvidia-bfs, eg. packages? (Decluding nvidia-utils*, of course.)
As far as I can think of, I can't see any downside(s) (whatsoever) of using those *-all packages instead of those 'specifc-kernel' packages, since they do in fact auto-detect all the kernels on the system.
Now to the important part: what do you think?
Det
Hi, nvidia-beta-all may be suitable for multikernel installation, but prevents you from having installed various versions of nvidia driver in each kernel (when a regression is introduced in some kernel for example) or having none driver installed for a particular kernel at all. I myself use the dual-kernel setup, one with nvidia-beta and one with nouveau drivers. This option would be lost If only nvidia-beta-all would be available, since it would install nvidia kernel module everywhere. And I believe that nvidia/nouveau is one of the most common reasons for people to have multiple kernels installed. I'd suggest to keep nvidia-beta-all and nvidia-beta packages, (because nvidia- beta uses uname -r to detect current running kernel) and get rid of all those nvidia-beta-whateverkernelhaveeverbeeninaur packages. Regards, Dan PS: I'm maintainer of nvidia-beta, but I'm not lobbying for keeping it because I don't want to lose a package, but as a result of my reasoning and expectations of user comfort. -- --- Dan Vrátil dan@progdan.cz Tel.: +420732326870 Jabber: progdan@jabber.cz Tento email neobsahuje žádné viry, protože odesílatel nepoužívá Windows. / This email does not contain any viruses because the sender does not use Windows.
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
2011/3/31 Det <nimetonmaili@gmail.com>:
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.
On Fri, Apr 1, 2011 at 1:39 AM, Rémy Oudompheng <remyoudompheng@gmail.com> wrote:
2011/3/31 Det <nimetonmaili@gmail.com>:
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.
On 2011/3/31 Oon-Ee Ng <ngoonee.talk@gmail.com> wrote:
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.
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. 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. -- Rémy.
Thanks for your response Rémy, On Fri, Apr 1, 2011 at 7:54 AM, Rémy Oudompheng <remyoudompheng@gmail.com> 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) =)
participants (6)
-
Christos Nouskas
-
Dan Vratil
-
Det
-
Ike Devolder
-
Oon-Ee Ng
-
Rémy Oudompheng