Hi there!
On Wed, 02 Nov 2011 22:19:26 +0100, Yaroslav Halchenko wrote:
On Wed, 02 Nov 2011, Roger Leigh wrote:
When considering the divide between internal use and for users,
consider that if it's for users to invoke then it should simply be
in the default path. It's not typical to need to
although this topic faded away and irrelevant anyways since upcoming FHS
forbids directories under /usr/bin -- just for completeness and
possible food for thought
And if you have to type in the full path every time that would be pretty
anoying and no improvement over /usr/lib/foo/bar.
Le Thu, Nov 17, 2011 at 09:28:19AM +0100, Luca Capello a écrit :
On Wed, 02 Nov 2011 22:19:26 +0100, Yaroslav Halchenko wrote:
Well -- that is all cool and in an ideal world I am with you on this
one. BUT it is often the case (e.g. with scientific software) that
suite provide bulk of
Yaroslav Halchenko deb...@onerussian.com writes:
Thank you John for extending my argument with adequate references which
I have swallowed while composing my question email.
And if we are after reading FHS /usr/lib section:
/usr/lib includes object files, libraries, and internal
]] Henrique de Moraes Holschuh
| Not that I care either way, libexec really is fluff, but at least it is
| harmless fluff that will cost us one inode in / and one inode in /usr so
| if people want it, I certainly won't get in the way.
I'd be more annoying with it breaking tab-completion than
Marvin Renich m...@renich.org writes:
How is /usr/libexec/package better than /usr/lib/package in these
cases?
Placing executables in /usr/lib/package is just messy, if it contains,
for instance, libraries. Having binaries in /usr/lib/package/bin, as
inn2 does, is a bit better at least.
--
Le lundi 07 novembre 2011 à 01:26 +0100, Andreas Bombe a écrit :
I for one could see the tcpd case make sense… It does not belong on
root's $PATH, but since it needs to be available to other packages (such
as inetd) it can't be put in /usr/lib/$PACKAGE because then calling it
would depend on
[Ian Jackson]
2. Obviously the right answer with a standardisation decision you
don't like is to wait until (a) it's implemented everywhere and
(b) the people you originally disagreed with have moved on to
other things, and then to change the standard to be the way you
always
On Sun, 06 Nov 2011, Steve Langasek wrote:
On Sun, Nov 06, 2011 at 11:36:05PM +, Clint Adams wrote:
On Sun, Nov 06, 2011 at 04:25:32PM +0100, Josselin Mouette wrote:
What is the use case?
The use case is to have a place for executables that are treated
similarly to libraries by
Josselin Mouette j...@debian.org writes:
We already have $pkglibdir and $pkgdatadir for those. There is no
technical need for a new directory in /usr, and it doesn’t improve
anything for users.
Possibly not for the users, but it _certainly_ improves the environment
for system and application
* Stig Sandbeck Mathisen s...@debian.org [07 09:55]:
Josselin Mouette j...@debian.org writes:
We already have $pkglibdir and $pkgdatadir for those. There is no
technical need for a new directory in /usr, and it doesn’t improve
anything for users.
Possibly not for the users, but it
On Mon, Nov 07, 2011 at 04:33:33PM +0100, Stig Sandbeck Mathisen wrote:
Josselin Mouette j...@debian.org writes:
We already have $pkglibdir and $pkgdatadir for those. There is no
technical need for a new directory in /usr, and it doesnt improve
anything for users.
Possibly not for the
On Sun, Nov 06, 2011 at 01:09:31AM +0100, Josselin Mouette wrote:
Le vendredi 04 novembre 2011 à 21:21 +, Ben Hutchings a écrit :
It's not a GNU invention; I believe it derives from BSD.
I stand corrected. That doesn’t make it have any more sense, though.
Apparently it's for
On Sun, 2011-11-06 at 01:09 +0100, Josselin Mouette wrote:
Le vendredi 04 novembre 2011 à 21:21 +, Ben Hutchings a écrit :
It's not a GNU invention; I believe it derives from BSD.
I stand corrected. That doesn’t make it have any more sense, though.
Apparently it's for executables
On Sat, 5 Nov 2011 16:51:14 +
Ian Jackson ijack...@chiark.greenend.org.uk wrote:
Clint Adams writes (Re: directory under /usr/bin -- Ok or not?):
On Fri, Nov 04, 2011 at 09:46:20PM +0100, Josselin Mouette wrote:
I don?t think Debian requests FHS to document something before we
can
On Sat, Nov 05, 2011 at 04:51:14PM +, Ian Jackson wrote:
1. There is still no good reason for libexec.
Of course there is.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
Le dimanche 06 novembre 2011 à 14:46 +, Clint Adams a écrit :
On Sat, Nov 05, 2011 at 04:51:14PM +, Ian Jackson wrote:
1. There is still no good reason for libexec.
Of course there is.
What is the use case?
--
.''`. Josselin Mouette
: :' :
`. `'
`-
signature.asc
On Sun, Nov 06, 2011 at 04:25:32PM +0100, Josselin Mouette wrote:
What is the use case?
The use case is to have a place for executables that are treated
similarly to libraries by other executables.
For example, tcpd gets run by inetd but not by humans, so it
would be silly to have it on root's
On Sun, Nov 06, 2011 at 11:36:05PM +, Clint Adams wrote:
On Sun, Nov 06, 2011 at 04:25:32PM +0100, Josselin Mouette wrote:
What is the use case?
The use case is to have a place for executables that are treated
similarly to libraries by other executables.
For example, tcpd gets run by
On Sun, Nov 06, 2011 at 11:36:05PM +, Clint Adams wrote:
On Sun, Nov 06, 2011 at 04:25:32PM +0100, Josselin Mouette wrote:
What is the use case?
The use case is to have a place for executables that are treated
similarly to libraries by other executables.
For example, tcpd gets run by
On 7 November 2011 11:26, Andreas Bombe a...@debian.org wrote:
The sftp-server on the other hand is provided by the package that also
contains its only caller AFAICS. That should be in /usr/lib/$PACKAGE
together with other package specific binary stuff — it doesn't make a
difference whether
On Mon, 7 Nov 2011 12:24:35 +1100
Brian May br...@microcomaustralia.com.au wrote:
On 7 November 2011 11:26, Andreas Bombe a...@debian.org wrote:
The sftp-server on the other hand is provided by the package that
also contains its only caller AFAICS. That should be
in /usr/lib/$PACKAGE
Clint Adams writes (Re: directory under /usr/bin -- Ok or not?):
On Fri, Nov 04, 2011 at 09:46:20PM +0100, Josselin Mouette wrote:
I don?t think Debian requests FHS to document something before we can
use it. The real problem with the bizarre GNU invention that
is /usr/libexec
Oh and:
Clint Adams writes (Re: directory under /usr/bin -- Ok or not?):
On Fri, Nov 04, 2011 at 09:46:20PM +0100, Josselin Mouette wrote:
I don?t think Debian requests FHS to document something before we can
use it. The real problem with the bizarre GNU invention that
is /usr/libexec
Le vendredi 04 novembre 2011 à 21:21 +, Ben Hutchings a écrit :
It's not a GNU invention; I believe it derives from BSD.
I stand corrected. That doesn’t make it have any more sense, though.
Apparently it's for executables that don't belong in the path (rarely
used from interactive shells
Igor Pashev pashev.i...@gmail.com writes:
Isn't /usr/libexec for internal use exetutables?
Other places, yes. Not in the FHS.
So, being halfway serious: Debian wants FHS to document it before we can
use it, and the FHS wants to document current practice. Clearly, we need
someone in the Fedora
Le vendredi 04 novembre 2011 à 21:00 +0100, Stig Sandbeck Mathisen a
écrit :
So, being halfway serious: Debian wants FHS to document it before we can
use it, and the FHS wants to document current practice. Clearly, we need
someone in the Fedora project to start using /usr/libexec first. :)
I
On Fri, Nov 04, 2011 at 09:46:20PM +0100, Josselin Mouette wrote:
Le vendredi 04 novembre 2011 à 21:00 +0100, Stig Sandbeck Mathisen a
écrit :
So, being halfway serious: Debian wants FHS to document it before we can
use it, and the FHS wants to document current practice. Clearly, we need
On Fri, Nov 04, 2011 at 09:46:20PM +0100, Josselin Mouette wrote:
I don’t think Debian requests FHS to document something before we can
use it. The real problem with the bizarre GNU invention that
is /usr/libexec is that nobody knows what it is here for.
Allegedly it was going to be in the FHS
Ben Hutchings b...@decadent.org.uk writes:
I don’t think Debian requests FHS to document something before we can
use it. The real problem with the bizarre GNU invention that
is /usr/libexec is that nobody knows what it is here for.
It's not a GNU invention; I believe it derives from BSD.
Le mercredi 02 novembre 2011 à 19:15 -0400, Yaroslav Halchenko a
écrit :
thanks Cyril -- that indeed clarifies it (finally)!
it is all clear now that users would need to invoke them from under
/usr/lib/
No, they would need to invoke them using a wrapper in /usr/bin. Think of
“git foo” or
03.11.2011 00:48, Roger Leigh пишет:
When considering the divide between internal use and for users,
consider that if it's for users to invoke then it should simply be
in the default path. It's not typical to need to add special
directories to one's path, and it's certainly not encouraged or
On Thu, 03 Nov 2011 at 22:58:38 +0400, Igor Pashev wrote:
Isn't /usr/libexec for internal use exetutables?
In the GNU coding standards and on Red Hat-based distributions, yes; in the
FHS (and hence Debian), no. (libexec isn't specified by the FHS.)
S
--
To UNSUBSCRIBE, email to
well -- correct but ...
,---
|
http://www.pathname.com/fhs/pub/fhs-2.3.html#LIBLTQUALGTALTERNATEFORMATESSENTIAL
| /libqual : Alternate format essential shared libraries (optional)
| Purpose
|
| There may be one or more variants of the /lib directory on systems which
support more than one binary
On Thu, Nov 03, 2011 at 07:21:59PM +, Simon McVittie wrote:
On Thu, 03 Nov 2011 at 22:58:38 +0400, Igor Pashev wrote:
Isn't /usr/libexec for internal use exetutables?
In the GNU coding standards and on Red Hat-based distributions, yes; in the
FHS (and hence Debian), no. (libexec isn't
Am 03.11.2011 21:47, schrieb Ben Hutchings:
On Thu, Nov 03, 2011 at 07:21:59PM +, Simon McVittie wrote:
On Thu, 03 Nov 2011 at 22:58:38 +0400, Igor Pashev wrote:
Isn't /usr/libexec for internal use exetutables?
In the GNU coding standards and on Red Hat-based distributions, yes; in the
Do we have any policy/recommendation forbidding/disadvising having
subdirectories under /usr/bin?
Conventionally, for packages which ship bulk of command line tools with
possible naming conflicts we seems to place them under /usr/lib/PACKAGE
(often regardless them being arch-dep or not)
I am
On Nov 02, Yaroslav Halchenko deb...@onerussian.com wrote:
Do we have any policy/recommendation forbidding/disadvising having
subdirectories under /usr/bin?
We have the FHS, which says that you do not do this.
--
ciao,
Marco
signature.asc
Description: Digital signature
On Wed, Nov 02, 2011 at 01:31:06PM -0400, Yaroslav Halchenko wrote:
Do we have any policy/recommendation forbidding/disadvising having
subdirectories under /usr/bin?
Conventionally, for packages which ship bulk of command line tools with
possible naming conflicts we seems to place them under
Marco d'Itri wrote:
On Nov 02, Yaroslav Halchenko deb...@onerussian.com wrote:
Do we have any policy/recommendation forbidding/disadvising having
subdirectories under /usr/bin?
We have the FHS, which says that you do not do this.
Where? Section 4.5. /usr/bin Most User Commands[1]
Thank you John for extending my argument with adequate references which
I have swallowed while composing my question email.
And if we are after reading FHS /usr/lib section:
/usr/lib includes object files, libraries, and internal binaries that
are not intended to be executed directly by
Thank you Steve !
With all due respect -- I disagree with your lines of
reasoning/support.
The per-package subdir should be created instead under
/usr/lib, and /usr/bin/cmtk can dispatch subcommands over there.
as I and John argued, FHS doesn't mandate them to be
under /usr/lib and actually
On Wed, Nov 02, 2011 at 03:43:08PM -0400, Yaroslav Halchenko wrote:
Thank you John for extending my argument with adequate references which
I have swallowed while composing my question email.
And if we are after reading FHS /usr/lib section:
/usr/lib includes object files, libraries,
On Wed, 02 Nov 2011, Roger Leigh wrote:
Altogether, according to FHS /usr/lib/PKG is actually not preferable
location for them since indeed it is for solely internal use (and it is
now used to keep shared libraries)
This is just nitpicking over the precise wording used.
really? since
On Wed, Nov 02, 2011 at 03:53:04PM -0400, Yaroslav Halchenko wrote:
Thank you Steve !
With all due respect -- I disagree with your lines of
reasoning/support.
The per-package subdir should be created instead under
/usr/lib, and /usr/bin/cmtk can dispatch subcommands over there.
as I and
thanks once again
Your understanding is misguided. If you intend it to be a user interface,
it belongs on the PATH. If you don't, it belongs under /usr/lib.
I hear you regarding that ideally they should be on the PATH...
but -- nothing in FHS talks about PATH.
thoughts aloud:
science
On Wed, 2 Nov 2011 13:31:06 -0400
Yaroslav Halchenko deb...@onerussian.com wrote:
Do we have any policy/recommendation forbidding/disadvising having
subdirectories under /usr/bin?
[...]
I have checked FHS which only says:
The following directories, or symbolic links to directories, must be
On Wed, 2 Nov 2011 18:41:20 -0400
Yaroslav Halchenko deb...@onerussian.com wrote:
thanks once again
Your understanding is misguided. If you intend it to be a user
interface, it belongs on the PATH. If you don't, it belongs
under /usr/lib.
I hear you regarding that ideally they
On Wed, 02 Nov 2011, Yaroslav Halchenko wrote:
really? since when it is nitpicking to quote FHS verbatim? once
again:
The following directories, or symbolic links to directories, must be in
/usr/bin, if the corresponding subsystem is installed:
Directory Description
mh
Karl Goetz k...@kgoetz.id.au (03/11/2011):
I don't have a link at the moment (because linuxfoundation
bugzilla/bzr/etc is still MIA), but I'm pretty sure its been clarified
forbidding subdirs in any of the (s)bin directories for FHS 3.0 (and
the exceptions you cite have also been removed).
On Thu, 03 Nov 2011, Karl Goetz wrote:
Not sure what you're trying to suggest here? The FHS *is* clear on what
goes in /usr/games:
games Games and educational binaries (optional)
I wasn't really suggesting anything I guess... just objected suggested
PATH-driven interpretation of what goes
thanks Cyril -- that indeed clarifies it (finally)!
it is all clear now that users would need to invoke them from under
/usr/lib/
Cheers,
P.S. so no need for me to repost it to fhs-discuss now I guess ;)
On Thu, 03 Nov 2011, Cyril Brulebois wrote:
In the meanwhile, posted by Jeff Licquia[2]:
On Wed, 2 Nov 2011 19:11:11 -0400
Yaroslav Halchenko deb...@onerussian.com wrote:
On Thu, 03 Nov 2011, Karl Goetz wrote:
Not sure what you're trying to suggest here? The FHS *is* clear on
what goes in /usr/games:
games Games and educational binaries (optional)
I wasn't really
Am 03.11.2011 00:15, schrieb Yaroslav Halchenko:
it is all clear now that users would need to invoke them from under
/usr/lib/
If at all, the binaries would need to be placed into
/usr/lib/package. But as Steve already said, if those binaries are
part of the interface and supposed to be called
54 matches
Mail list logo
