FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 11-15-2011, 05:19 PM
Goswin von Brederlow
 
Default directory under /usr/bin -- Ok or not?

Yaroslav Halchenko <debian@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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87obwdqmdh.fsf@frosties.localnet">http://lists.debian.org/87obwdqmdh.fsf@frosties.localnet
 
Old 11-17-2011, 07:28 AM
Luca Capello
 
Default 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>
 
Old 11-17-2011, 09:02 PM
Yaroslav Halchenko
 
Default 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/foo<TAB> -- 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111117220231.GA14900@onerussian.com">http://lists.debian.org/20111117220231.GA14900@onerussian.com
 
Old 11-18-2011, 12:12 AM
Charles Plessy
 
Default 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111118011252.GF16548@merveille.plessy.net">http://lists.debian.org/20111118011252.GF16548@merveille.plessy.net
 

Thread Tools




All times are GMT. The time now is 06:40 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org