Re: Installing package *NOT* in repository
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.
Reply to: