11:21 a.m.
They are:
/usr/bin/abrt-pyhook-helper
/usr/libexec/hookCCpp
Both names and paths are different.
I propose using abrt-xxx scheme for every binary's name
(btw, maybe for dumpoops too?).
That will fix one discrepancy - in the name.
Does it make sense to move abrt-pyhook-helper to /usr/libexec?
Currently, we are using the fact that it is in /usr/bin
by not specifying the /path/to/it when we call it:
command = ["abrt-pyhook-helper"]
command.append("--pid=%s" % pid)
command.append("--executable=%s" % executable)
command.append("--uuid=%s" % tb_uuid)
I usually like this, but here it maybe isn't the best idea.
What if /usr/bin is NOT in the $PATH at this point, in this python
script?
If we decide to have a full path there, then also moving to /usr/libexec
looks like a no-brainer.
What say you?
--
vda
11:59 a.m.
Dne 26.11.2009 18:21, Denys Vlasenko napsal(a):
They are:
/usr/bin/abrt-pyhook-helper
/usr/libexec/hookCCpp
Both names and paths are different.
I propose using abrt-xxx scheme for every binary's name
(btw, maybe for dumpoops too?).
That will fix one discrepancy - in the name.
Definitely yes. I'm loudly thinking about abrt-cpp-hook and abrt-dumpsoops.
Does it make sense to move abrt-pyhook-helper to /usr/libexec?
I don't get it why /usr/libexec exist.
--
vda
I suggest to have both files(helper and hook) in one directory.
Question is where? /usr/bin or /usr/libexec?
--
Nikola
12:09 p.m.
On Thu, 2009-11-26 at 18:59 +0100, Nikola Pajkovsky wrote:
Dne 26.11.2009 18:21, Denys Vlasenko napsal(a):
> They are:
>
> /usr/bin/abrt-pyhook-helper
> /usr/libexec/hookCCpp
>
> Both names and paths are different.
>
> I propose using abrt-xxx scheme for every binary's name
> (btw, maybe for dumpoops too?).
> That will fix one discrepancy - in the name.
Definitely yes. I'm loudly thinking about abrt-cpp-hook and abrt-dumpsoops.
> Does it make sense to move abrt-pyhook-helper to /usr/libexec?
I don't get it why /usr/libexec exist.
Perhaps the idea is that you put stuff there which
you don't want to be accessible through $PATH,
so it has less chance to be accidentally run.
Usually stuff which is meant to be never run
from command line and such.
--
vda
1:21 p.m.
26.11.2009 19:09, Denys Vlasenko wrote:
> I don't get it why /usr/libexec exist.
Perhaps the idea is that you put stuff there which
you don't want to be accessible through $PATH,
so it has less chance to be accidentally run.
Usually stuff which is meant to be never run
from command line and such.
Yeah, that's it. Program helpers that are not supposed to be run by
human user belong there. Abrt hooks strike me as an example of a binary
that belongs to libexec.
PM
3:51 a.m.
On 11/26/2009 06:21 PM, Denys Vlasenko wrote:
They are:
/usr/bin/abrt-pyhook-helper
/usr/libexec/hookCCpp
Both names and paths are different.
I propose using abrt-xxx scheme for every binary's name
(btw, maybe for dumpoops too?).
That will fix one discrepancy - in the name.
Does it make sense to move abrt-pyhook-helper to /usr/libexec?
Currently, we are using the fact that it is in /usr/bin
by not specifying the /path/to/it when we call it:
command = ["abrt-pyhook-helper"]
command.append("--pid=%s" % pid)
command.append("--executable=%s" % executable)
command.append("--uuid=%s" % tb_uuid)
I usually like this, but here it maybe isn't the best idea.
What if /usr/bin is NOT in the $PATH at this point, in this python
script?
If we decide to have a full path there, then also moving to /usr/libexec
looks like a no-brainer.
What say you?
--
+1 to abrt-xxxx naming scheme
And I would move all hooks to /usr/libexec as this is where helpers
should be.
Jirka
vda
5288
days inactive
5289
days old
crash-catcher@lists.fedorahosted.org
4 comments
4 participants
participants (4)
-
Denys Vlasenko -
Jiri Moskovcak -
Nikola Pajkovsky -
Petr Machata