On Fri 17 Aug 2018 at 07:31:34 (-0400), Gene Heskett wrote: > On Friday 17 August 2018 05:29:07 Vincent Lefevre wrote: > > > On 2018-08-13 09:38:48 -0300, Samuel Henrique wrote: > > > If you pass a file as parameter to apt install, like: > > > apt install ./package.deb > > > It will work, at least on buster. > > > > And the "./" is important, otherwise it will not work (until now, > > for this reason, I didn't know that passing a file was supported). > > I don't know the exact rule, but it seems that the pathname needs > > to start with either "/", "./" or "../". > > The effect is where the search for the given file is anchored > just a plain filename is assumed to be someplace in the $PATH
It would be very odd to place a package file into one's $PATH. Without knowing how this undocumented feature is implemented (and with no desire to use it), I can only assume that a naked filename would be interpreted as a *package* name rather than a *file* name. > / means its in the root directory > ./ means its in the current directory the shell is cd'd to > ../ means its one directory level above the currently cd'd to directory … and if file paths like dira/file.deb are not supported, again I can only assume that their problem is that / is used already to specify a release version. It's easy to write ./dira/file.deb instead. I don't know the rationale for overloading install's argument so heavily, rather than introducing an option like, say, -f. After all, unlike apt-get, apt explicitly warns that the commandline specification is not guaranteed stable. (All written assuming this facility exists as reported.) Cheers, David.
