[Crash-catcher] inconsistent hook names and locations

[Denys Vlasenko]

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

[Nikola Pajkovsky]

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?

[Denys Vlasenko]

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

[Petr Machata]

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

[Jiri Moskovcak]

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