On Sun, Sep 18, 2011 at 11:37:45PM +0200, ext David Faure wrote:
we do need a way to find kdesu, kioexec, drkonqi,
i'll just point out that these examples are flawed as arguments for
shared locations:
- kdesu is in libexec for plain wrong reasons. it should have stayed in
bin in the first
On Sunday 18 September 2011 01:48:12 Thiago Macieira wrote:
On Saturday, 17 de September de 2011 22:13:08 David Faure wrote:
That's my question to this list :-))
Actually, thinking about it, I have one idea:
appending /libexec to every entry in LD_LIBRARY_PATH.
Would that work?
That
On Sunday 18 September 2011 09:59:57 Sune Vuorela wrote:
On 2011-09-17, David Faure fa...@kde.org wrote:
Debian and friends uses more or less /usr/lib/NAME/libexec
where as fedora and friends uses /usr/libexec/NAME/
What's NAME there? The package name, in order to split up the helper
On Sun, 18 Sep 2011, David Faure wrote:
Well OK, appending /Qt/libexec to every entry in LD_LIBRARY_PATH (plus default
library paths like /usr/lib or /usr/lib64 somehow...)
Somehow I feel a bit uneasy about a global search such as this. See below.
I meant if a 64-bit library
On 2011-09-18, Harri Porten por...@froglogic.com wrote:
Do we have to? Isn't the individual apps part exactly what makes up
libexec? Shouldn't the search be tied to an application - or rather
library? Instead of a global search it'd be a search based on a hint for
I'm also started to wonder
On Sunday 18 September 2011 13:53:48 Thiago Macieira wrote:
/usr/libexec/OrganisationName/ApplicationName
just like /usr/share/OrganisationName/ApplicationName
Typical view that on top of Qt, there are only standalone applications.
It's time for Qt developers to realize that there can also be
On Sun, 18 Sep 2011, David Faure wrote:
Harri and Sune: I agree, we don't need to put all helpers into the same dir,
but we do need a way to find kdesu, kioexec, drkonqi, and so on from any
kde application for instance, so it's not just about per-application stuff
either. The base directory
On Saturday, 17 de September de 2011 11:36:26 Thiago Macieira wrote:
Tell me this: how would you write code that searches for a generic libexec
(no kde4 in the pathname) and yet allows KDE to find its helper tools?
I think this thread has gone off in the wrong direction. Let's go back to
Does Qt have the concept of a libexec directory?
I.e. a directory that contains executables that are used by library code, and
that shouldn't be in $PATH so as not to bother users.
I'm porting code to QStandardPaths::findExecutable, and realizing that it only
looks in PATH, so it doesn't have
On Saturday, 17 de September de 2011 10:54:25 David Faure wrote:
Does Qt have the concept of a libexec directory?
I.e. a directory that contains executables that are used by library code,
and that shouldn't be in $PATH so as not to bother users.
I'm porting code to
On 2011-09-17, Thiago Macieira thi...@kde.org wrote:
Tell me this: how would you write code that searches for a generic libexec
(no
kde4 in the pathname) and yet allows KDE to find its helper tools?
And even write one generic enough to work across distributions.
Debian and friends uses more
On Saturday, 17 de September de 2011 10:07:20 Sune Vuorela wrote:
On 2011-09-17, Thiago Macieira thi...@kde.org wrote:
Tell me this: how would you write code that searches for a generic libexec
(no kde4 in the pathname) and yet allows KDE to find its helper tools?
And even write one generic
On Saturday 17 September 2011 14:34:20 Thiago Macieira wrote:
On Saturday, 17 de September de 2011 10:07:20 Sune Vuorela wrote:
On 2011-09-17, Thiago Macieira thi...@kde.org wrote:
Tell me this: how would you write code that searches for a generic
libexec (no kde4 in the pathname) and yet
On Saturday, 17 de September de 2011 22:13:08 David Faure wrote:
That's my question to this list :-))
Actually, thinking about it, I have one idea:
appending /libexec to every entry in LD_LIBRARY_PATH.
Would that work?
That would get you /usr/lib/libexec, which is neither what we have nor
On 18/09/2011, at 9:48 AM, Thiago Macieira wrote:
The big difference there is whether those executables are
architecture-specific in multiarch configurations (e.g.,
/usr/lib64/NAME/libexec). Usually they aren't.
How could an executable not be architecture-specific? I must be missing
something.
15 matches
Mail list logo
