Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #198689 > unrolled thread

Installing package *NOT* in repository

Back to article view | Back to linux.debian.user

Contents

  Installing package *NOT* in repository Richard Owlett <rowlett@cloud85.net> - 2018-08-13 13:50 +0200
    Re: Installing package *NOT* in repository Joe <joe@jretrading.com> - 2018-08-13 14:00 +0200
      Re: Installing package *NOT* in repository Richard Owlett <rowlett@cloud85.net> - 2018-08-13 14:30 +0200
        Re: Installing package *NOT* in repository Samuel Henrique <samueloph@debian.org> - 2018-08-13 14:40 +0200
          Re: Installing package *NOT* in repository Vincent Lefevre <vincent@vinc17.net> - 2018-08-17 11:30 +0200
            Re: Installing package *NOT* in repository Gene Heskett <gheskett@shentel.net> - 2018-08-17 13:40 +0200
              Re: Installing package *NOT* in repository Richard Owlett <rowlett@cloud85.net> - 2018-08-17 14:30 +0200
                Re: Installing package *NOT* in repository Reco <recoverym4n@gmail.com> - 2018-08-17 14:50 +0200
                  Re: Installing package *NOT* in repository Richard Owlett <rowlett@cloud85.net> - 2018-08-17 17:00 +0200
              Re: Installing package *NOT* in repository David Wright <deblis@lionunicorn.co.uk> - 2018-08-17 20:50 +0200
                Re: Installing package *NOT* in repository Vincent Lefevre <vincent@vinc17.net> - 2018-08-21 13:00 +0200
                  Re: Installing package *NOT* in repository Gene Heskett <gheskett@shentel.net> - 2018-08-21 14:10 +0200
                    Re: Installing package *NOT* in repository <tomas@tuxteam.de> - 2018-08-21 14:50 +0200
                      Re: Installing package *NOT* in repository Greg Wooledge <wooledg@eeg.ccf.org> - 2018-08-21 15:40 +0200
                        Re: Installing package *NOT* in repository Michael Stone <mstone@debian.org> - 2018-08-21 16:40 +0200
                      Re: Installing package *NOT* in repository David Wright <deblis@lionunicorn.co.uk> - 2018-08-21 17:10 +0200
                        Re: Installing package *NOT* in repository <tomas@tuxteam.de> - 2018-08-21 17:40 +0200
                        Re: Installing package *NOT* in repository Gene Heskett <gheskett@shentel.net> - 2018-08-21 19:30 +0200
                    Re: Installing package *NOT* in repository David Wright <deblis@lionunicorn.co.uk> - 2018-08-21 17:10 +0200
                      Re: Installing package *NOT* in repository Greg Wooledge <wooledg@eeg.ccf.org> - 2018-08-21 17:30 +0200
                        Re: Installing package *NOT* in repository Michael Stone <mstone@debian.org> - 2018-08-21 18:00 +0200
                        Re: Installing package *NOT* in repository David Wright <deblis@lionunicorn.co.uk> - 2018-08-21 19:00 +0200
        Re: Installing package *NOT* in repository Joe <joe@jretrading.com> - 2018-08-13 15:00 +0200
        Re: Installing package *NOT* in repository Zenaan Harkness <zenaan@freedbms.net> - 2018-08-13 16:10 +0200
    Re: Installing package *NOT* in repository john doe <johndoe65534@mail.com> - 2018-08-13 14:10 +0200
    Re: Installing package *NOT* in repository Matthew Crews <mailinglists@mattcrews.com> - 2018-08-13 15:00 +0200
      Re: Installing package *NOT* in repository <tomas@tuxteam.de> - 2018-08-13 15:50 +0200
    Re: Installing package *NOT* in repository Patrick Bartek <nemommxiv@gmail.com> - 2018-08-13 17:40 +0200
      Re: Installing package *NOT* in repository <tomas@tuxteam.de> - 2018-08-13 17:50 +0200
        Re: Installing package *NOT* in repository Samuel Henrique <samueloph@debian.org> - 2018-08-13 18:00 +0200
          Re: Installing package *NOT* in repository tomas@tuxteam.de - 2018-08-13 18:20 +0200
            Re: Installing package *NOT* in repository Brian <ad44@cityscape.co.uk> - 2018-08-13 18:50 +0200
              Re: Installing package *NOT* in repository Curt <curty@free.fr> - 2018-08-13 19:10 +0200
                Re: Installing package *NOT* in repository Brian <ad44@cityscape.co.uk> - 2018-08-13 19:30 +0200
        Re: Installing package *NOT* in repository Brian <ad44@cityscape.co.uk> - 2018-08-13 18:00 +0200
          Re: Installing package *NOT* in repository Cindy-Sue Causey <butterflybytes@gmail.com> - 2018-08-14 19:50 +0200
            Re: Installing package *NOT* in repository Jason <electron@emypeople.net> - 2018-08-15 13:10 +0200
        Re: Installing package *NOT* in repository Patrick Bartek <nemommxiv@gmail.com> - 2018-08-14 04:10 +0200
          Re: Installing package *NOT* in repository <tomas@tuxteam.de> - 2018-08-14 09:00 +0200
            Re: Installing package *NOT* in repository Patrick Bartek <nemommxiv@gmail.com> - 2018-08-14 17:00 +0200
              Re: Installing package *NOT* in repository <tomas@tuxteam.de> - 2018-08-14 17:30 +0200
    Re: Installing package *NOT* in repository songbird <songbird@anthive.com> - 2018-08-14 05:50 +0200
    Re: Installing package *NOT* in repository Erik Christiansen <dvalin@internode.on.net> - 2018-08-14 08:50 +0200
      Re: Installing package *NOT* in repository Richard Owlett <rowlett@cloud85.net> - 2018-08-14 13:50 +0200
        Re: Installing package *NOT* in repository Erik Christiansen <dvalin@internode.on.net> - 2018-08-15 07:10 +0200
          Re: Installing package *NOT* in repository Kenneth Parker <sea7kenp@gmail.com> - 2018-08-15 07:30 +0200
            Re: Installing package *NOT* in repository <tomas@tuxteam.de> - 2018-08-15 10:00 +0200
            Re: Installing package *NOT* in repository Darac Marjal <mailinglist@darac.org.uk> - 2018-08-15 10:30 +0200
          Re: Installing package *NOT* in repository Zenaan Harkness <zenaan@freedbms.net> - 2018-08-15 08:20 +0200

Page 1 of 3  [1] 2 3  Next page →

#198689 — Installing package *NOT* in repository

PREAMBLE:
I've downloaded a .deb file.
I've recently done such an install but don't remember how.
Looking at the man pages for apt, apt-get, aptitude didn't help.
Couldn't come up with useful search term for wiki.
Eventually recalled "dpkg -i" which worked.

QUESTION:
How would someone find the answer if the answer wasn't already known?
I went thru the same sequence last time.

[toc] | [next] | [standalone]

#198690

On Mon, 13 Aug 2018 06:47:02 -0500
Richard Owlett <rowlett@cloud85.net> wrote:

> PREAMBLE:
> I've downloaded a .deb file.
> I've recently done such an install but don't remember how.
> Looking at the man pages for apt, apt-get, aptitude didn't help.
> Couldn't come up with useful search term for wiki.
> Eventually recalled "dpkg -i" which worked.
> 
> QUESTION:
> How would someone find the answer if the answer wasn't already known?
> I went thru the same sequence last time.
> 

https://www.google.co.uk/search?q=install+.deb&gws_rd=ssl

First hit:
https://unix.stackexchange.com/questions/159094/how-to-install-a-deb-file-by-dpkg-i-or-by-apt

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#198694

On 08/13/2018 06:59 AM, Joe wrote:
> On Mon, 13 Aug 2018 06:47:02 -0500
> Richard Owlett <rowlett@cloud85.net> wrote:
> 
>> PREAMBLE:
>> I've downloaded a .deb file.
>> I've recently done such an install but don't remember how.
>> Looking at the man pages for apt, apt-get, aptitude didn't help.
>> Couldn't come up with useful search term for wiki.
>> Eventually recalled "dpkg -i" which worked.
>>
>> QUESTION:
>> How would someone find the answer if the answer wasn't already known?
>> I went thru the same sequence last time.
>>
> 
> https://www.google.co.uk/search?q=install+.deb&gws_rd=ssl
> 
> First hit:
> https://unix.stackexchange.com/questions/159094/how-to-install-a-deb-file-by-dpkg-i-or-by-apt
> 

A partial "mea culpa" ;/
I was completely focused on Debian tools and never thought of searching 
the whole web.

My gut feeling is still there should be a way to use Debian tools.

Thank you for your time.

[toc] | [prev] | [next] | [standalone]

#198695

[Multipart message — attachments visible in raw view] — view raw

If you pass a file as parameter to apt install, like:
apt install ./package.deb
It will work, at least on buster.

A partial "mea culpa" ;/
> I was completely focused on Debian tools and never thought of searching
> the whole web.
>
> My gut feeling is still there should be a way to use Debian tools.
>

It would be nice if this was documented on the apt manpage, i have a strong
feeling that it's just a matter of opening a bug report asking for it, or
even better, sending a patch to the maintainers. Whatever suits you better.

Regards,

-- 
Samuel Henrique <samueloph>

[toc] | [prev] | [next] | [standalone]

#198919

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 "../".

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[toc] | [prev] | [next] | [standalone]

#198927

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
/ 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


-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#198930

On 08/17/2018 06:31 AM, 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
> / 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
> 
> 

Can an absolute path [/home/richard/mydebs/aname.deb] be given?

[toc] | [prev] | [next] | [standalone]

#198931

	Hi.

On Fri, Aug 17, 2018 at 07:27:01AM -0500, Richard Owlett wrote:
> On 08/17/2018 06:31 AM, 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
> > / 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
> > 
> > 
> 
> Can an absolute path [/home/richard/mydebs/aname.deb] be given?

Yes. Checked out this useful feature myself today.
Absolute pathname definitely works.

Reco

[toc] | [prev] | [next] | [standalone]

#198942

On 08/17/2018 07:44 AM, Reco wrote:
> 	Hi.
> 
> On Fri, Aug 17, 2018 at 07:27:01AM -0500, Richard Owlett wrote:
>> On 08/17/2018 06:31 AM, 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
>>> / 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
>>>
>>>
>>
>> Can an absolute path [/home/richard/mydebs/aname.deb] be given?
> 
> Yes. Checked out this useful feature myself today.
> Absolute pathname definitely works.
> 

Samuel Henrique has already suggested that a bug report against the 
apt(8) man page is needed. APT(8) doesn't address the issue directly but 
does reference APT.CONF(5) which has sections titled "HOW APT CALLS 
DPKG(1)" and "DIRECTORIES" which appear relevant. I'll have to get my 
head around what they are attempting to get across. Won't have time 
until next week.

[toc] | [prev] | [next] | [standalone]

#198953

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.

[toc] | [prev] | [next] | [standalone]

#199137

On 2018-08-17 13:48:11 -0500, David Wright wrote:
> 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.

Yes, the use of $PATH is awkward. PATH is where executable files are
searched for. But Debian packages are not executable.

But I doubt that this is true. If I use a plain filename, strace
doesn't show any attempt to look at the file anywhere.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[toc] | [prev] | [next] | [standalone]

#199139

On Tuesday 21 August 2018 06:56:45 Vincent Lefevre wrote:

> On 2018-08-17 13:48:11 -0500, David Wright wrote:
> > 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.
>
> Yes, the use of $PATH is awkward. PATH is where executable files are
> searched for. But Debian packages are not executable.
>
Which is why for dpkg|apt work, you should cd to the location of the deb, 
and give it the package name in ./name.deb format.

Or, give it /the/full/path/to/the/package/name.deb.

> But I doubt that this is true. If I use a plain filename, strace
> doesn't show any attempt to look at the file anywhere.

Odd, maybe apt does not look in $PATH? That, in some $PATH environments, 
would be a huge time waster when its not expected to be there anyway.

I haven't tried it, but maybe a apt install <name.deb might work? But if 
it shoots the neighbors cat...?

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#199142

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, Aug 21, 2018 at 08:02:02AM -0400, Gene Heskett wrote:

[...]

> Odd, maybe apt does not look in $PATH?

There's no reason to assume that, unless when looking for an executable
(i.e. those things which tend to live in /bin and /usr/bin).

Actually, dpkg's man page mentions $PATH, but only for searching
executables, which is to be expected. Not for searching packages.

To me, it would be a surprise.

Cheers
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlt8ChkACgkQBcgs9XrR2kaf0gCeLbewH84ROf9mMcjaCa7s/+eZ
6vAAni9A0wRYe1a8RIv41Bkz5Jiojq7I
=I5OO
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#199144

On Tue, Aug 21, 2018 at 02:48:25PM +0200, tomas@tuxteam.de wrote:
> On Tue, Aug 21, 2018 at 08:02:02AM -0400, Gene Heskett wrote:
> > Odd, maybe apt does not look in $PATH?

(That wouldn't be "odd".  That would be "normal".)

> There's no reason to assume that, unless when looking for an executable
> (i.e. those things which tend to live in /bin and /usr/bin).
> 
> Actually, dpkg's man page mentions $PATH, but only for searching
> executables, which is to be expected. Not for searching packages.
> 
> To me, it would be a surprise.

Y'know what, I'm getting sick of apt having this feature and not
documenting it anywhere.  So I decided to do an "apt-get source apt"
and try to find it in the freakin' code.

Unfortunately, it is written in C++.  It is a nightmare.  Totally
unreadable.

I managed to find the file apt-1.4.8/cmdline/apt.cc which looks like
the starting point for the "apt" command line tool.  So, yay?  We can
start here, right?  Hah!

The "obvious" thing that I found was this:

      // package stuff
      {"install", &DoInstall, _("install packages")},

So, if we pass the command "install", it should call this function named
"DoInstall", right?  So all we have to do is find the function named
"DoInstall" somewhere in the source code, and read that, and it will
tell us what the "install" command does.  Right?

Wrong.  Because it's an unmaintinable C++ nightmare.

Oh, but, here's main() and in main() we see this call:

   auto const Cmds = ParseCommandLine(CmdL, APT_CMD::APT, &_config, &_system, argc, argv, &ShowHelp, &GetCommands);

So, we can just find the function named "ParseCommandLine" and read THAT,
and surely THAT would have to tell us how it parses the command line
arguments, right?  RIGHT?!

Wrong.  Because it's an unreadable C++ nightmare.

I also tried looking for "strchr" (thinking, "somewhere there HAS to be
a check to see whether the argument string contains a slash character,
right?").  I found a few of them, but none seemed relevant.

I even tried doing searches for "'/'" (that is, the three-character
literal string '/') in a few places, but no luck with that either.

Oh, you know what else?  Here in the top-level directory there's this
file named README.md and it says:

  APT uses cmake.

At that point, I just gave up.  cmake is the WORST.  As near as I
can tell, it exists for only one reason: to make development hellish.
As soon as I saw that this project uses cmake, I literally gave up,
wrote this screed, and deleted the source directory.

Someone else can try to find the god damned argument parsing code.
Which should be in the god damned main() function.  But isn't.

[toc] | [prev] | [next] | [standalone]

#199147

On Tue, Aug 21, 2018 at 09:33:31AM -0400, Greg Wooledge wrote:
>Y'know what, I'm getting sick of apt having this feature and not
>documenting it anywhere.  So I decided to do an "apt-get source apt"
>and try to find it in the freakin' code.

The relevant test is:

      if (I != nullptr && (I[0] == '/' || (I[0] == '.' && (I[1] == '\0' || (I[1] == '.' && (I[2] == '\0' || I[2] == '/')) || I[1] == '/'))))

So, basically, if the argument starts with / or ./ or ../ (or if the 
argument is . or ..) it's processed directly.

Mike Stone

[toc] | [prev] | [next] | [standalone]

#199148

On Tue 21 Aug 2018 at 14:48:25 (+0200), tomas@tuxteam.de wrote:
> On Tue, Aug 21, 2018 at 08:02:02AM -0400, Gene Heskett wrote:
> 
> [...]
> 
> > Odd, maybe apt does not look in $PATH?
> 
> There's no reason to assume that, unless when looking for an executable
> (i.e. those things which tend to live in /bin and /usr/bin).

… and then it will of course be hashed, and so waste no time at all.
But Gene's mention of $PATH was a complete red herring. Or cargo cult.

And consider this: it would be seriously mental to place downloaded
files, which might even have been obtained from untrusted sources,
and stick them in your $PATH ready for execution.

> Actually, dpkg's man page mentions $PATH, but only for searching
> executables, which is to be expected. Not for searching packages.

Yes, and I think one can see why dpkg explicitly mentions $PATH. It
uses a lot of helper programs for unpacking archives, computing MD5s,
etc, and $PATH is where they're expected to be. Expected, but people
using dpkg from the commandline might well have seriously broken
systems with missing or incompatible binaries, and --force-bad-path
attempts to deal with that.

> To me, it would be a surprise.

IMO it would be a grave bug in the Debian project's thinking.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#199153

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, Aug 21, 2018 at 10:06:31AM -0500, David Wright wrote:
> On Tue 21 Aug 2018 at 14:48:25 (+0200), tomas@tuxteam.de wrote:

[...]

> > To me, it would be a surprise.
> 
> IMO it would be a grave bug in the Debian project's thinking.

I was trying my hand at some kind of British understatement :)

Cheers
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlt8MbIACgkQBcgs9XrR2kYu8QCaA63dZ15xjloxkGlpUxBYHLFc
IbAAnAjH9f8EJ4BBJQmARg/s+r6dTwDc
=fTyv
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#199172

On Tuesday 21 August 2018 11:06:31 David Wright wrote:

> On Tue 21 Aug 2018 at 14:48:25 (+0200), tomas@tuxteam.de wrote:
> > On Tue, Aug 21, 2018 at 08:02:02AM -0400, Gene Heskett wrote:
> >
> > [...]
> >
> > > Odd, maybe apt does not look in $PATH?
> >
> > There's no reason to assume that, unless when looking for an
> > executable (i.e. those things which tend to live in /bin and
> > /usr/bin).
>
> … and then it will of course be hashed, and so waste no time at all.
> But Gene's mention of $PATH was a complete red herring. Or cargo cult.
>
> And consider this: it would be seriously mental to place downloaded
> files, which might even have been obtained from untrusted sources,
> and stick them in your $PATH ready for execution.

I think would be inventing a new word, stoooooppidd.

> > Actually, dpkg's man page mentions $PATH, but only for searching
> > executables, which is to be expected. Not for searching packages.
>
> Yes, and I think one can see why dpkg explicitly mentions $PATH. It
> uses a lot of helper programs for unpacking archives, computing MD5s,
> etc, and $PATH is where they're expected to be. Expected, but people
> using dpkg from the commandline might well have seriously broken
> systems with missing or incompatible binaries, and --force-bad-path
> attempts to deal with that.
>
> > To me, it would be a surprise.
>
> IMO it would be a grave bug in the Debian project's thinking.
>
> Cheers,
> David.



-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#199149

On Tue 21 Aug 2018 at 08:02:02 (-0400), Gene Heskett wrote:
> On Tuesday 21 August 2018 06:56:45 Vincent Lefevre wrote:
> 
> > On 2018-08-17 13:48:11 -0500, David Wright wrote:
> > > 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.
> >
> > Yes, the use of $PATH is awkward. PATH is where executable files are
> > searched for. But Debian packages are not executable.
> >
> Which is why for dpkg|apt work, you should cd to the location of the deb, 

Why? The rule above (start with either "/", "./" or "../") doesn't
necessitate that.

> and give it the package name in ./name.deb format.
> 
> Or, give it /the/full/path/to/the/package/name.deb.
> 
> > But I doubt that this is true. If I use a plain filename, strace
> > doesn't show any attempt to look at the file anywhere.

Yes, logical. (Be aware that "But I doubt that this is true"
refers to the lines starting "The effect is where the search for …").

> Odd, maybe apt does not look in $PATH? That, in some $PATH environments, 
> would be a huge time waster when its not expected to be there anyway.

Why would you expect it to look for a «file» at all? If you write
    # apt install gem.deb
then apt should try to install any «packages» it finds called
"gemadeb", "gembdeb", "gemcdeb", "gemddeb", etc, and will
consequently install the «package» gem2deb, which is likely
not what you expected unless you read the man page for apt-get
in combination with that for apt.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#199152

On Tue, Aug 21, 2018 at 10:04:58AM -0500, David Wright wrote:
> Why would you expect it to look for a «file» at all? If you write
>     # apt install gem.deb
> then apt should try to install any «packages» it finds called
> "gemadeb", "gembdeb", "gemcdeb", "gemddeb", etc, and will
> consequently install the «package» gem2deb, which is likely
> not what you expected unless you read the man page for apt-get
> in combination with that for apt.

First of all, the . character is valid in a package name, and is supposed
to be treated literally.  A package named python3.5 exists, for example.

The . character can be a single-character wildcard in some kinds of
regular expression, but one would hope (I certainly hope) that when
an exactly matching package name exists in the database, the exact
match should win out over a regex(7) match.

The . character is NOT a single-character wildcard to the shell, so it
does not need escaping or quoting to survive the shell's argument
parsing.  You might be thinking of the ? character.

Second, this whole thread has been about the undocumented feature of
apt (but not apt-get) that allows you to specify a pathname to a .deb
file on an "apt install" command.  Nobody was quite sure how it worked,
because it's undocumented.

However, Michael Stone was kind enough to point out the line of code
which is partly responsible for this feature (thank you).  So, now we
know that "apt install" can take a pathname argument, but only if the
pathname begins with "/" or "./" or "../".  This seems like a strange
choice to me (I would've gone with "contains a slash", because there's
precedent for that, and because it allows pathnames like "foo/bar.deb"
which the current code does not allow).  But at least now we know.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | linux.debian.user

csiph-web