Re: directory under /usr/bin -- Ok or not?
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 add special directories to one's path, and it's certainly not encouraged or recommended. 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 (100) cmdline tools. Some of those come without unique names and are already widely used by people running Debian or whatnot, so changing their habbits/scripts is not as easy as lets just renamed them. Sure thing we recommend upstream either coming up with custom prefixes/unique names or gateway wrappers to avoid conflicts and/or reduce hit on the proliferation of namespace of cmdline tools... But once again -- it ain't happening at once and for all, so let's not discuss this aspect further here. Exactly, discussion about this practice (which, BTW, is coded in Policy), was at: http://bugs.debian.org/190753 Thx, bye, Gismo / Luca PS, I am researcher in biology and hate this practice of providing bulk of cmdline tools with generic name: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642986#10 pgpagb5LfNspT.pgp Description: PGP signature
Re: directory under /usr/bin -- Ok or not?
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. disagree -- actually it would be quite better: now, without any standardization of what/where gets under /usr/lib/foo, some projects ship binaries under /usr/lib/foo directly, some under /usr/lib/foo/bin, others under /usr/lib/foo/libexec... moreover for versioned ones it also varies pretty much orthogonally to above between /usr/lib/foo-01, or /usr/lib/foo/01 ... So, location of such complimentary, possibly user-oriented, executables varies a lot and there is no easy way for a user to find them -- when I am looking for what/where a specific package provides additional scripts I need to dpkg -L foo and then eyeball it. If all supplementary user-oriented scripts where under /usr/bin/foo(-version), it would have made their invocation much more convenient (if I know that I am looking an executable from foo I don't need first to research where it is -- I would know that if anywhere it is under /usr/bin/fooTAB -- directory it or a file) even though I would have needed to type a full path, since their location would be uniform. Just my few cents -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2017220231.ga14...@onerussian.com
Re: directory under /usr/bin -- Ok or not?
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 (100) cmdline tools. Some of those come without unique names and are already widely used by people running Debian or whatnot, so changing their habbits/scripts is not as easy as lets just renamed them. Sure thing we recommend upstream either coming up with custom prefixes/unique names or gateway wrappers to avoid conflicts and/or reduce hit on the proliferation of namespace of cmdline tools... But once again -- it ain't happening at once and for all, so let's not discuss this aspect further here. Exactly, discussion about this practice (which, BTW, is coded in Policy), was at: http://bugs.debian.org/190753 Hi Luca, note that this policy is drastically biased. For instance, why foo.pl has to be renamed and gtk-bar not ? They both convey the same message, and there is no way to determine a priori if foo.py or qt-bar are drop-in replacements or completely unrelated programs. I think that it is a matter of time before we create Debian-specific conflicts that do not exist upstream. We see more and more conflicts and it is a good thing. I think that people have not become less careful than before, but it is just that the community of developers increased, the quantity of Free software produced increased, and the proportion of beginners error stays the same. I think that we can not make the economy of supporting multiple namespaces. If the policy on the main namespace is draconian and creates incompatiblities between Debian and the rest of the world, then we need easy mechanisms for our users to switch namespaces. Perhaps the Debian Pure Blends are a good tool for this… Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2018011252.gf16...@merveille.plessy.net
Re: directory under /usr/bin -- Ok or not?
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 binaries that are not intended to be executed directly by users or shell scripts. and in my case it becomes more interesting -- those tools *are intended* to be executed by (interested) users directly. It is just due to proliferation in number of the tools and conflicts with other packages they cannot go under /usr/bin directly. But if you have /usr/bin/foo/bar then how is the user supposed to execute it? foo/bar won't work. 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. I would rather use /usr/bin/foo-bar in that case, e.g. git-import-dsc. That is why for this package (as for few others we maintain already) we are shipping also /etc/PKG/pkg.sh script so (interested) users could source to have their PATH adjusted to get preference to execute tools from the PKG instead of possibly available conflicting one under /usr/bin. Wrapper script shipped directly under /usr/bin/ is only for possible future adoption since at the moment all users (and their scripts) rely on direct names of the cmdline tools. Adding /usr/lib/PKG to the PATH seems just a viable. As for wrapper scripts. If you can put a wrapper script in /usr/bin then you can just as easily just put the binary there in the first place. 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) There you might have a point. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87obwdqmdh.fsf@frosties.localnet
Re: directory under /usr/bin -- Ok or not?
]] 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 the extra inode. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fwhxteit@qurzaw.varnish-software.com
Re: directory under /usr/bin -- Ok or not?
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. -- Stig Sandbeck Mathisen s...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/7xhb2ehpo8@fsck.linpro.no
Re: directory under /usr/bin -- Ok or not?
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 knowing the package providing that binary, an implementation detail that might change. Nothing forces us to use /usr/lib/$PACKAGE. For a common interface shared between several packages, it is frequent to use /usr/lib/somethingelse. -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1320657178.3189.112.camel@pi0307572
Re: directory under /usr/bin -- Ok or not?
[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 wanted it to be. Same as with science, I guess. :) A new scientific truth does not triumph by convincing its opponents and making them see the light, but rather because its opponents eventually die, and a new generation grows up that is familiar with it. (Max Planck) -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2flaa888dnn@login1.uio.no
Re: directory under /usr/bin -- Ok or not?
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 other executables. For example, tcpd gets run by inetd but not by humans, so it would be silly to have it on root's PATH, so you put it in libexec. sftp-server gets run by sshd but is not a library, so it would be silly to have it in /usr/lib, so you put it in libexec. What is the justification for making this a separate directory from /usr/lib (especially given that /usr/lib has now been part of Debian policy AFAIK there is none [in Linux], but the fact that a very large number of others do it anyway, and it is not exactly going to cause technical problems to diverge less from upstream in this specific issue. libexec really exists as something to offload stuff that would end up in /usr/sbin and /sbin to. We've been using lib for that for a long time without any issues, so we don't really *need* to do it. for a decade or so)? What is the transition plan for migrating from /usr/lib to /usr/libexec? Do we even need one? If upstream places stuff in libexec and is not on crack, you move that stuff back into libexec *if you want to, as the maintainer of the package*. If you don't care for libexec, or if upstream doesn't use libexec anyway, you keep using lib. 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. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2007101315.ga2...@khazad-dum.debian.net
Re: directory under /usr/bin -- Ok or not?
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 administrators. Some applications (for instance: inn and mailman) have a lot of executables which only makes sense when you're in the context of that application user, so having a /usr/libexec/package in the path for that user makes life as an application administrator easier. -- Stig Sandbeck Mathisen s...@debian.org pgpREX4hqQHeC.pgp Description: PGP signature
Re: directory under /usr/bin -- Ok or not?
* 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 _certainly_ improves the environment for system and application administrators. Some applications (for instance: inn and mailman) have a lot of executables which only makes sense when you're in the context of that application user, so having a /usr/libexec/package in the path for that user makes life as an application administrator easier. How is /usr/libexec/package better than /usr/lib/package in these cases? ...Marvin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2007172734.gb4...@cleo.wdw
Re: directory under /usr/bin -- Ok or not?
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 users, but it _certainly_ improves the environment for system and application administrators. Some applications (for instance: inn and mailman) have a lot of executables which only makes sense when you're in the context of that application user, so having a /usr/libexec/package in the path for that user makes life as an application administrator easier. That seems no different from having, say, /usr/lib/news/bin in the path, as at present. Nick -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2007180152.ga15...@leverton.org
Re: directory under /usr/bin -- Ok or not?
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 executables that don't belong in the path (rarely used from interactive shells or scripts). We already have $pkglibdir and $pkgdatadir for those. Those serve a different purpose. There's also a $pkglibexecdir, which is explicitly for that purpose. It's very odd that as an upstream (where Debian is the upstream!), I'm using $pkglibexecdir and then have to make it the same as $pkglibdir for no good reason. I would typically be using $pkglibdir for loadable modules and the like, rather than executables. libexecdir is a good place for executables called by programs rather than by users. I'd like to be able to make use of it. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2007183132.gm28...@codelibre.net
Re: directory under /usr/bin -- Ok or not?
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 that don't belong in the path (rarely used from interactive shells or scripts). 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. It's widespread practice and doesn't seem to do any harm. So it seems like a waste of time to continue fighting it. Ben. -- Ben Hutchings You can't have everything. Where would you put it? signature.asc Description: This is a digitally signed message part
Re: directory under /usr/bin -- Ok or not?
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 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 but a couple of Debian loudmouths whined until it was omitted for no good reason. As one of those loudmouths: 1. There is still no good reason for libexec. 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 wanted it to be. A few months ago when libexec was brought up on the FHS list [1], I couldn't find any list archive with the original discussions. Other then the bugzilla (which is unfortunately MIA atm...) do you know where people can look for the last round of discussion? Without any of the people originally involved in fhs 2.x being involved in 3.x (TTBOMK) and no historical reference its not entirely surprising that a different choice is being made. (Note here I'm not taking a stance on if it should be in or not). [1] elseware in the thread i saw a sourceforce fhs-discuss list. Is that the one? If so I'll go digging there. thanks, kk -- Karl Goetz, (Kamping_Kaiser / VK7FOSS) http://www.kgoetz.id.au No, I won't join your social networking group signature.asc Description: PGP signature
Re: directory under /usr/bin -- Ok or not?
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: http://lists.debian.org/2006144613.ga31...@scru.org
Re: directory under /usr/bin -- Ok or not?
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 Description: This is a digitally signed message part
Re: directory under /usr/bin -- Ok or not?
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 PATH, so you put it in libexec. sftp-server gets run by sshd but is not a library, so it would be silly to have it in /usr/lib, so you put it in libexec. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2006233605.ga12...@scru.org
Re: directory under /usr/bin -- Ok or not?
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 inetd but not by humans, so it would be silly to have it on root's PATH, so you put it in libexec. sftp-server gets run by sshd but is not a library, so it would be silly to have it in /usr/lib, so you put it in libexec. What is the justification for making this a separate directory from /usr/lib (especially given that /usr/lib has now been part of Debian policy for a decade or so)? What is the transition plan for migrating from /usr/lib to /usr/libexec? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: directory under /usr/bin -- Ok or not?
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 inetd but not by humans, so it would be silly to have it on root's PATH, so you put it in libexec. sftp-server gets run by sshd but is not a library, so it would be silly to have it in /usr/lib, so you put it in libexec. 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 knowing the package providing that binary, an implementation detail that might change. 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 it's linked, dlopen()ed or exec()ed. One could say public non-$PATH binaries should just go in /usr/lib instead of a subdir then. However there's the problem with name collisions with package subdirs. Libraries don't have that problem what with them all being named *.a or *.so*. I see sftp-server is in /usr/lib as a link to openssh-server and that happens to work. tcpd wouldn't, for example. /usr/libexec would provide a convenient separate namespace. As would /usr/lib/bin, but let's not go there. Anyway, just throwing that out there. -- Andreas Bombe -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2007002637.ga7...@amos.fritz.box
Re: directory under /usr/bin -- Ok or not?
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 it's linked, dlopen()ed or exec()ed. I think we are talking about /usr/lib, not /usr/lib/$PACKAGE (?). On my Ubuntu system /usr/lib already has some binaries, although some might be just for backward compatibility: lrwxrwxrwx 1 root root 19 2011-07-30 02:02 /usr/lib/sftp-server - openssh/sftp-server* lrwxrwxrwx 1 root root 16 2011-10-07 15:20 /usr/lib/sendmail - ../sbin/sendmail* -rwxr-xr-x 1 root root 2532 2011-09-22 22:35 /usr/lib/command-not-found* -rwxr-xr-x 1 root root 10528 2011-03-18 05:09 /usr/lib/e2initrd_helper* -rwsr-xr-x 1 root root 10592 2011-10-05 07:58 /usr/lib/pt_chown* /usr/lib has so many files, maybe there might be performance reasons for splitting it up, depending on what filesystem you have? -- Brian May br...@microcomaustralia.com.au -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caa0zo6dbte0+evusvx953eh3f2dsou-sdcx1bptumpmfmz9...@mail.gmail.com
Re: directory under /usr/bin -- Ok or not?
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 together with other package specific binary stuff — it doesn't make a difference whether it's linked, dlopen()ed or exec()ed. I think we are talking about /usr/lib, not /usr/lib/$PACKAGE (?). On my Ubuntu system /usr/lib already has some binaries, although some might be just for backward compatibility: lrwxrwxrwx 1 root root 19 2011-07-30 02:02 /usr/lib/sftp-server - openssh/sftp-server* lrwxrwxrwx 1 root root 16 2011-10-07 15:20 /usr/lib/sendmail - ../sbin/sendmail* This is mandated by the fhs 2.x /usr/share/doc/debian-policy/fhs/fhs-2.3.txt.gz : Specific Options For historical reasons, /usr/lib/sendmail must be a symbolic link to /usr/sbin/ sendmail if the latter exists. [24] Removing it for 3.x was discussed, i don't remember the result offhand. /usr/lib has so many files, maybe there might be performance reasons for splitting it up, depending on what filesystem you have? FYI, /usr/libexec was discussed in deb-dev in 2005 [1], and performance was mentioned a couple of times ([2] being an example). You'll have to browse the thread to see the arguments for/against :) [1] http://lists.debian.org/debian-devel/2005/05/msg00401.html [2] http://lists.debian.org/debian-devel/2005/05/msg00434.html thanks, kk -- Karl Goetz, (Kamping_Kaiser / VK7FOSS) http://www.kgoetz.id.au No, I won't join your social networking group signature.asc Description: PGP signature
Re: directory under /usr/bin -- Ok or not?
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 is that nobody knows what it is here for. Allegedly it was going to be in the FHS but a couple of Debian loudmouths whined until it was omitted for no good reason. As one of those loudmouths: 1. There is still no good reason for libexec. 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 wanted it to be. Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20149.27010.890304.260...@chiark.greenend.org.uk
Re: directory under /usr/bin -- Ok or not?
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 is that nobody knows what it is here for. Allegedly it was going to be in the FHS but a couple of Debian loudmouths whined until it was omitted for no good reason. As one of those loudmouths: ... 2. Obviously the right answer with a standardisation decision you don't like is to ... 2b. Complain that the fact you lost the argument the last time was due to whining. Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20149.27089.614119.978...@chiark.greenend.org.uk
Re: directory under /usr/bin -- Ok or not?
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 or scripts). 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. -- .''`. Josselin Mouette : :' : `. `' `- signature.asc Description: This is a digitally signed message part
Re: directory under /usr/bin -- Ok or not?
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 project to start using /usr/libexec first. :) -- Stig Sandbeck Mathisen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vcqzlktc@debian.org
Re: directory under /usr/bin -- Ok or not?
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 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. -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1320439580.3968.17.camel@tomoyo
Re: directory under /usr/bin -- Ok or not?
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 someone in the Fedora project to start using /usr/libexec first. :) 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. On a real FreeBSD system (not the Debian mash-up) it contains: atrun lint1 rpc.rusersd bootpd lint2 rpc.rwalld bootpgw locate.bigram rpc.sprayd catman.locallocate.code rshd cc1 locate.concatdb save-entropy cc1obj locate.mklocatedb sendmail cc1plus locate.updatedb sftp-server comsat lpr sm.bin fingerd mail.local smrsh ftpdmake_index ssh-keysign getty makewhatis.localssh-pkcs11-helper hprop mknetid tcpd hpropd ntalkd telnetd ipropd-master phttpgettftp-proxy ipropd-slavepppoed tftpd kadmind rbootd vfontedpr kcm revnetgroup yppwupdate kdc rlogind ypxfr kpasswddrpc.rquotad ld-elf.so.1 rpc.rstatd Very little of that is related to GNU. Apparently it's for executables that don't belong in the path (rarely used from interactive shells or scripts). Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2004212145.gd3...@decadent.org.uk
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 is that nobody knows what it is here for. Allegedly it was going to be in the FHS but a couple of Debian loudmouths whined until it was omitted for no good reason. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2004212851.ga6...@scru.org
Re: directory under /usr/bin -- Ok or not?
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. Yes, it originally came from BSD. Seems to make good sense too. -Miles -- We live, as we dream -- alone -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874nyj1556@catnip.gol.com
Re: directory under /usr/bin -- Ok or not?
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 “svn blah” as good examples to follow. -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1320308733.3334.370.camel@pi0307572
Re: directory under /usr/bin -- Ok or not?
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 recommended. Isn't /usr/libexec for internal use exetutables? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4eb2e45e.1080...@gmail.com
Re: directory under /usr/bin -- Ok or not?
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 debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2003192159.gc12...@reptile.pseudorandom.co.uk
Re: directory under /usr/bin -- Ok or not?
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 format requiring separate libraries. [14] | Requirements | | If one or more of these directories exist, the requirements for their contents are the same as the normal /lib directory, except that /libqual/cpp is not required. [15] `--- discussion about having /lib/libexec in Debian has happened around 5-6 years ago and it was agreed just to dump everything under the universal dump -- /usr/lib On Thu, 03 Nov 2011, Simon McVittie 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.) -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2003200934.gr10...@onerussian.com
Re: directory under /usr/bin -- Ok or not?
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 specified by the FHS.) Is there any movement to fix this (by specifying /usr/libexec) now that FHS is being updated? Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2003204750.gy3...@decadent.org.uk
Re: directory under /usr/bin -- Ok or not?
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 FHS (and hence Debian), no. (libexec isn't specified by the FHS.) Is there any movement to fix this (by specifying /usr/libexec) now that FHS is being updated? The 3.0 draft does contain /usr/libexec -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
directory under /usr/bin -- Ok or not?
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 packaging CMTK, where upstream agreed also to deliver a wrapper script (/usr/bin/cmtk) so there would be a single point of entry to run any needed command (in similar fashion to git), but also he made all cmdline tools become available from ... /usr/bin/CMTK I have checked FHS which only says: The following directories, or symbolic links to directories, must be in /usr/bin... so it seems to be ok to have subdirectories under /usr/bin (for /bin there is strict must not), and I failed to find something in debian policy forbidding or allowing taht. So would it be ok? I kinda like that setup because then user doesn't need to search anywhere under /usr/lib for a script I need from CMTK -- it becomes available where I would expect it to find -- under /usr/bin(/CMTK) -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2002173106.gh10...@onerussian.com
Re: directory under /usr/bin -- Ok or not?
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
Re: directory under /usr/bin -- Ok or not?
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 /usr/lib/PACKAGE (often regardless them being arch-dep or not) I am packaging CMTK, where upstream agreed also to deliver a wrapper script (/usr/bin/cmtk) so there would be a single point of entry to run any needed command (in similar fashion to git), but also he made all cmdline tools become available from ... /usr/bin/CMTK I have checked FHS which only says: The following directories, or symbolic links to directories, must be in /usr/bin... so it seems to be ok to have subdirectories under /usr/bin (for /bin there is strict must not), and I failed to find something in debian policy forbidding or allowing taht. So would it be ok? No, it's not ok. The per-package subdir should be created instead under /usr/lib, and /usr/bin/cmtk can dispatch subcommands over there. /usr/bin is on the path. Subdirs of /usr/bin are not on the path and should not have to be added. Therefore there is no point in having subdirs of /usr/bin, regardless of whether the FHS currently makes it explicit that it's prohibited. (It actually *is* a requirement from the FHS, because the FHS says that a subdir in /usr/lib is the place where things must be placed; there's just no backlink from the definition of /usr/bin that makes this clear without reading the full FHS for context.) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: directory under /usr/bin -- Ok or not?
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] specfically allows directories, going so far as to explictly mentioning one directory, and mandating a link to another directory. You may be thinking of Section 3.4.2 Requirements[2] which forbids directories; however that section refers only to /bin. [1] http://www.pathname.com/fhs/pub/fhs-2.3.pdf pg 19 [1] http://www.pathname.com/fhs/pub/fhs-2.3.pdf pg 5 -- John H. Robinson, IV jaq...@debian.org http WARNING: I cannot be held responsible for the above, sbih.org ( )(:[ as apparently my cats have learned how to type. spiders.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2002182428.ga4...@a.mx.sbih.org
Re: directory under /usr/bin -- Ok or not?
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 users or shell scripts. and in my case it becomes more interesting -- those tools *are intended* to be executed by (interested) users directly. It is just due to proliferation in number of the tools and conflicts with other packages they cannot go under /usr/bin directly. That is why for this package (as for few others we maintain already) we are shipping also /etc/PKG/pkg.sh script so (interested) users could source to have their PATH adjusted to get preference to execute tools from the PKG instead of possibly available conflicting one under /usr/bin. Wrapper script shipped directly under /usr/bin/ is only for possible future adoption since at the moment all users (and their scripts) rely on direct names of the cmdline tools. 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) On Wed, 02 Nov 2011, John H. Robinson, IV 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] specfically allows directories, going so far as to explictly mentioning one directory, and mandating a link to another directory. You may be thinking of Section 3.4.2 Requirements[2] which forbids directories; however that section refers only to /bin. [1] http://www.pathname.com/fhs/pub/fhs-2.3.pdf pg 19 [1] http://www.pathname.com/fhs/pub/fhs-2.3.pdf pg 5 -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2002194308.gi10...@onerussian.com
Re: directory under /usr/bin -- Ok or not?
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 allows for subdirectories under /usr/bin (more below) /usr/bin is on the path. 100% correct Subdirs of /usr/bin are not on the path also 100% correct, although could be made to be on the path (as any other directory) upon user's intent, and could be executed directly and should not have to be added. (It actually *is* a requirement from the FHS, because the FHS says that a subdir in /usr/lib is the place where things must be placed; there's just no backlink from the definition of /usr/bin that makes this clear without reading the full FHS for context.) as I have mentioned -- I see nowhere such a requirement, Moreover: - FHS seems to allow subdirectories under /usr/bin: The following directories, or symbolic links to directories, must be in /usr/bin ... and gives a nice example: mh Commands for the MH mail handling system (optional) - /usr/lib is destined for /usr/lib includes object files, libraries, and internal binaries that are not intended to be executed directly by users or shell scripts so indeed anything which cannot be executed directly -- should go there. But executed directly in my understanding is not solely being on the PATH -- if I can execute a tool via /usr/lib/PKG/bin/xxx -- it is direct execution and thus should not be hidden under /usr/lib -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2002195304.gj10...@onerussian.com
Re: directory under /usr/bin -- Ok or not?
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, and internal binaries that are not intended to be executed directly by users or shell scripts. and in my case it becomes more interesting -- those tools *are intended* to be executed by (interested) users directly. It is just due to proliferation in number of the tools and conflicts with other packages they cannot go under /usr/bin directly. [...] 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. In practice, this *is* where they belong, and it is what every other package does (for example, postgresql). You can add that specific directory to your path, should you choose. 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 recommended. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2002204856.gj28...@codelibre.net
Re: directory under /usr/bin -- Ok or not?
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 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 Commands for the MH mail handling system (optional) ? In practice, this *is* where they belong, and it is what every other package does (for example, postgresql). You can add that specific directory to your path, should you choose. and I have been doing that for quite a few packages myself -- so I am quite aware of this current common practice. And that is why I actually decided to check among standards and ask here either it is mandated, because I always felt that executing anything from /usr/lib felt awkward. You might consider me blind or naive -- but so far none of the arguments for not having a subdirectory under /usr/bin had any strongly supported argument. 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 recommended. 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 (100) cmdline tools. Some of those come without unique names and are already widely used by people running Debian or whatnot, so changing their habbits/scripts is not as easy as lets just renamed them. Sure thing we recommend upstream either coming up with custom prefixes/unique names or gateway wrappers to avoid conflicts and/or reduce hit on the proliferation of namespace of cmdline tools... But once again -- it ain't happening at once and for all, so let's not discuss this aspect further here. -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2002211926.gk10...@onerussian.com
Re: directory under /usr/bin -- Ok or not?
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 John argued, FHS doesn't mandate them to be under /usr/lib and actually allows for subdirectories under /usr/bin (more below) The subdirectories of /usr/bin that are allowed in the FHS are spelled out because they are exceptions. - /usr/lib is destined for /usr/lib includes object files, libraries, and internal binaries that are not intended to be executed directly by users or shell scripts so indeed anything which cannot be executed directly -- should go there. But executed directly in my understanding is not solely being on the PATH -- if I can execute a tool via /usr/lib/PKG/bin/xxx -- it is direct execution and thus should not be hidden under /usr/lib 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. It is a bug in the FHS that it allows for this interpretation, but I have no doubt that it is a bug and which way the FHS would be clarified to fix this hole. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: directory under /usr/bin -- Ok or not?
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 could indeed be considered a game -- may be I should advise on such PATH-driven interpretation and ask upstream to place their binaries under /usr/games then which is in the PATH -- then we should all be compliant with our intertrepations of FHS ;) damn... there is only 1 /usr/games so once again -- conflicts conflicts conflicts not sure if of any point, since the list seems to be only full of SPAM I have posted my question to [1]. [1] http://sourceforge.net/mailarchive/forum.php?thread_name=200553.GL10325%40onerussian.comforum_name=freestandards-fhs-discuss Cheers, On Wed, 02 Nov 2011, Steve Langasek wrote: 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 John argued, FHS doesn't mandate them to be under /usr/lib and actually allows for subdirectories under /usr/bin (more below) The subdirectories of /usr/bin that are allowed in the FHS are spelled out because they are exceptions. - /usr/lib is destined for /usr/lib includes object files, libraries, and internal binaries that are not intended to be executed directly by users or shell scripts so indeed anything which cannot be executed directly -- should go there. But executed directly in my understanding is not solely being on the PATH -- if I can execute a tool via /usr/lib/PKG/bin/xxx -- it is direct execution and thus should not be hidden under /usr/lib 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. It is a bug in the FHS that it allows for this interpretation, but I have no doubt that it is a bug and which way the FHS would be clarified to fix this hole. -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2002224119.gm10...@onerussian.com
Re: directory under /usr/bin -- Ok or not?
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 in /usr/bin... so it seems to be ok to have subdirectories under /usr/bin (for /bin there is strict must not), and I failed to find something in debian policy forbidding or allowing taht. So would it be ok? 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). If/when all the infrastructure comes back, you can find links to them at [1]. [1] http://lists.linuxfoundation.org/pipermail/fhs-discuss/2011-August/000334.html thanks, kk -- Karl Goetz, (Kamping_Kaiser / VK7FOSS) http://www.kgoetz.id.au No, I won't join your social networking group signature.asc Description: PGP signature
Re: directory under /usr/bin -- Ok or not?
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 should be on the PATH... but -- nothing in FHS talks about PATH. thoughts aloud: science could indeed be considered a game -- may be I should advise on such PATH-driven interpretation and ask upstream to place their binaries under /usr/games then which is in the PATH -- then we should all be compliant with our intertrepations of FHS ;) damn... there is only 1 /usr/games so once again -- conflicts conflicts conflicts 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) not sure if of any point, since the list seems to be only full of SPAM I have posted my question to [1]. [1] http://sourceforge.net/mailarchive/forum.php?thread_name=200553.GL10325%40onerussian.comforum_name=freestandards-fhs-discuss This is not the proper location for FHS discussion, [1] is. [1] https://lists.linux-foundation.org/mailman/listinfo/fhs-discuss thanks, kk -- Karl Goetz, (Kamping_Kaiser / VK7FOSS) http://www.kgoetz.id.au No, I won't join your social networking group signature.asc Description: PGP signature
Re: directory under /usr/bin -- Ok or not?
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 Commands for the MH mail handling system (optional) There are exactly two packages in Debian which have subdirectories in /usr/bin: mailutils-mh, and nmh. Nothing else does this, and having mh do it in the first place seems to be a historical mistake. [The only other slight exception is /usr/bin/X11, and we've done away with that by making it X11 a symlink to .] A package which uses names that are so general that it conflicts with existing binary names and thus can't be stuck in /usr/bin by default probably shouldn't be normally executed directly by users or scripts in the first place. It shouldn't be encouraged to put such a package's directories into PATH, either. Don Armstrong -- Herodotus says, Very few things happen at the right time, and the rest do not happen at all. The conscientious historian will correct these defects. -- Mark Twain _A Horse's Tail_ http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2002224627.gf26...@teltox.donarmstrong.com
Re: directory under /usr/bin -- Ok or not?
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). If/when all the infrastructure comes back, you can find links to them at [1]. [1] http://lists.linuxfoundation.org/pipermail/fhs-discuss/2011-August/000334.html In the meanwhile, posted by Jeff Licquia[2]: “This draft removes quite a few historical artifacts, such as /usr/X11R6 and subdirectories in /usr/bin, and adds many recent developments, including /sys and /run.” 2. https://www.linux.com/news/software/linux-kernel/493031:feedback-requested-filesystem-hierarchy-standard-released Which should clarify the situation. Mraw, KiBi. signature.asc Description: Digital signature
Re: directory under /usr/bin -- Ok or not?
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 under /usr/bin http://sourceforge.net/mailarchive/forum.php?thread_name=200553.GL10325%40onerussian.comforum_name=freestandards-fhs-discuss This is not the proper location for FHS discussion, [1] is. [1] https://lists.linux-foundation.org/mailman/listinfo/fhs-discuss ah -- thanks -- I just followed a link on http://www.pathname.com/fhs/ will repost to fhs-discuss now -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/200223.gn10...@onerussian.com
Re: directory under /usr/bin -- Ok or not?
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]: “This draft removes quite a few historical artifacts, such as /usr/X11R6 and subdirectories in /usr/bin, and adds many recent developments, including /sys and /run.” 2. https://www.linux.com/news/software/linux-kernel/493031:feedback-requested-filesystem-hierarchy-standard-released Which should clarify the situation. -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2002231536.go10...@onerussian.com
Re: directory under /usr/bin -- Ok or not?
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 suggesting anything I guess... just objected suggested
PATH-driven interpretation of what goes under /usr/bin
ok
http://sourceforge.net/mailarchive/forum.php?thread_name=200553.GL10325%40onerussian.comforum_name=freestandards-fhs-discuss
This is not the proper location for FHS discussion, [1] is.
[1] https://lists.linux-foundation.org/mailman/listinfo/fhs-discuss
ah -- thanks -- I just followed a link on
http://www.pathname.com/fhs/
Not sure who can fix that page, a few links need updating to the new
location. The page source mentions Daniel Quinlan, if you're interested
in following up perhaps try him.
will repost to fhs-discuss now
For FHS 3.0 its already changed to No subdirectories in {,/usr}/(s)bin.
thanks,
kk
--
Karl Goetz, (Kamping_Kaiser / VK7FOSS)
http://www.kgoetz.id.au
No, I won't join your social networking group
signature.asc
Description: PGP signature
Re: directory under /usr/bin -- Ok or not?
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 by the user, then they belong on the PATH. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
