My first question is: What is the difference between running dpkg -i
on a .deb file, and running apt install on a package name? From what I
have read, apt uses dpkg underneath, so I am confused as to why both
would be used in this case.
dpkg can be used exclusively on local files, while apt-get and more recently apt are tools designed to be used by the end user, and can be used both on local files and on repository based files. They are built on top of dpkg, meaning that they will still call it and use it to install whatever. They are, arguably, more user friendly. There shouldn't be any difference in calling apt or dpkg on a local .deb file. But only apt and apt-get can be used on remote files, meaning that they will automatically download and install them. I'm not sure, but apt might also take care of dependencies with local .deb files. It certainly does with repository based packages.
My second question is: What is telling my apt the meaning of cuda? I
understand how running dpkg on a local file will then install this
file, but I don't understand how the name cuda is linked with this
.deb file.
What is telling apt the meaning of cuda are your source files. From what I can tell, cuda are not in the default repositories, probably because it is proprietary software. So, if you try sudo apt install cuda out of the box it won't work, because it will look for it and won't find anything with this name.
What happens is that some programs, as part of their .deb installation file, add themselves to the sources list. Google chrome does something similar. When you download the google chrome .deb file (and your cuda program) they will, as part of their installation add a line to /etc/apt/sources.list or a file to /etc/apt/sources.list.d/, so whenever you run sudo apt update it will go to the link and download a source from them, and on this source there will be a mention of a package called cuda that you can install and be automatically upgraded as sudo apt upgrade. It is similar to adding a PPA. Some other programs add themselves to the sources as part of a bash installation script or they might ask you to add them manually. I believe the best reason to do this is ease of updating, as it will be automated as part of your regular updates.
My third question is: Let's say there is a newer version of this
package, which comes in a file called
cuda-repo-ubuntu1804_10.1_amd64.deb. What would happen if I were to
run sudo apt upgrade cuda? Would this remove all files for
cuda-repo-ubuntu1804_10.0.130-1_amd64.deb and install
cuda-repo-ubuntu1804_10.1_amd64.deb?
You should probably ask around the cuda forums for a more authoritative answer on this, and what is the proper process for updating to newer versions. Using the Google Chrome example, it will automatically update to the newer version, so it will remove the old one and keep only the new one. But this is very specific to this cuda package, and how they decided to handle things.
Maybe they use the cuda package that they add to the sources solely for dependencies and free software that they can't bundle with their proprietary package, so you would still need to download a new .deb file and install it. Maybe they use it to update everything, and it will automatically download and install the new version when you run the routinely sudo apt update && sudo apt upgrade. Again, very specific to this package, and you should ask on their support channels.
man dpkg: "dpkg is a tool to install, build, remove and manage Debian packages. The primary and more user-friendly front-end for dpkg is aptitude(1)". My guess is that theapttool relies on repositories, anddpkgis suited to handle individual (or multiple) packages. But the wise ones will have surely a comprehensive answer. – schrodingerscatcuriosity Sep 05 '19 at 15:41aptyou are sure that any package has complete dependencies (at least from the official repos), but withdpkgyou can install any package downloaded from x site, not knowing if the dependencies are satisfied. – schrodingerscatcuriosity Sep 05 '19 at 15:48