Re: shell script sniplets in /usr/bin?
#include * Santiago Vila [Sun, Jan 30 2005, 02:28:01PM]: > Where does dlsym() look up the libraries? In /usr/lib. So Debian > installs C libraries in /usr/lib/. Fine. That's wrong. Packages should avoid the installation of non-versioned (no SONAME) libraries in /usr/lib. Such plugins can often be loaded from special locations after minor changes in the program source. This is also often allowed and supported by upstream's configuration system. > Where does "." look up the libraries? Anywhere in $PATH. In particular in > /usr/bin. > > If the Debian project designates a particular directory for shell script > function libraries, and puts this directory in $PATH by default, GNU gettext > will happily install its contents there. Crap thinking. AFAICS no one of hundreds of maintainers came to the idea to put shell snippets there. ls /usr/bin/ -la | grep -v rwx | grep -v rws So why is your case different? > So, the common sense says /usr/bin is ok for gettext.sh, not the opposite. Common sense is something shareable with many other people. He presents only _his_ point of view. Regards, Eduard. -- schreibs meinetwegen in die fortunes :P -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shell script sniplets in /usr/bin?
On Sun, Jan 30, 2005 at 02:28:01PM +0100, Santiago Vila wrote:
> So, the common sense says /usr/bin is ok for gettext.sh, not the opposite.
s,common sense,convenience for the author/maintainer,
> If you want to make policy that /usr/bin should only contain executables,
> go ahead, make a policy proposal, but none of you have answered to the
think about the purpose path is supposed to serve. the bash man page
says PATH is "The search path for commands". it mentions nothing of
shell scripts to be included/sourced. i don't think a policy proposal
is necessary, i think all that is necessary is that you take a step
back from your situation and seriously reflect this.
> question made by Frank Küster:
>
> Do you think we should simply not make any use of the POSIX feature
> that . $name will look for $name in the $PATH? Or do you think we should
> add a directory to PATH that is then dedicated to such shell snippets?
i already provided a two methods which still allow for th is
functionality while not requiring you to drop gettext.sh in /usr/bin.
1)
(inside a gettext.sh using script)
#!/bin/sh
PATH=${PATH}:/usr/share/gettext/scripts
. gettext.sh
2)
#!/bin/sh
if [ "$GETTEXT_PATH" ]; then
GETTEXT="$GETTEXT_PATH"
else
GETTEXT="/usr/share/gettext/scripts/gettext.sh"
fi
. $GETTEXT
note that i'm not advocating you immediately change this, as someone
else pointed out this would break a lot of stuff. i am however
saying that your "that which is not explicitly denied must be allowed"
reasoning is flawed and is formed from your own bias to not have to
inconvenience yourself.
sean
--
signature.asc
Description: Digital signature
Re: shell script sniplets in /usr/bin?
On Sun, 30 Jan 2005, sean finney wrote: > think about the purpose path is supposed to serve. the bash man page > says PATH is "The search path for commands". it mentions nothing of > shell scripts to be included/sourced. This is from bash(1): . filename [arguments] source filename [arguments] Read and execute commands from filename in the current shell environment and return the exit status of the last command executed from filename. If filename does not contain a slash, filenames in PATH are used to find the directory containing filename. The file searched for in PATH need not be executable. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shell script sniplets in /usr/bin?
sean finney <[EMAIL PROTECTED]> writes:
> On Sun, Jan 30, 2005 at 02:28:01PM +0100, Santiago Vila wrote:
>> So, the common sense says /usr/bin is ok for gettext.sh, not the opposite.
>
> s,common sense,convenience for the author/maintainer,
>
>> If you want to make policy that /usr/bin should only contain executables,
>> go ahead, make a policy proposal, but none of you have answered to the
>
> think about the purpose path is supposed to serve. the bash man page
> says PATH is "The search path for commands". it mentions nothing of
> shell scripts to be included/sourced. i don't think a policy proposal
> is necessary, i think all that is necessary is that you take a step
> back from your situation and seriously reflect this.
>
>> question made by Frank Küster:
>>
>> Do you think we should simply not make any use of the POSIX feature
>> that . $name will look for $name in the $PATH? Or do you think we should
>> add a directory to PATH that is then dedicated to such shell snippets?
>
> i already provided a two methods which still allow for th is
> functionality while not requiring you to drop gettext.sh in /usr/bin.
>
> 1)
>
> (inside a gettext.sh using script)
>
> #!/bin/sh
> PATH=${PATH}:/usr/share/gettext/scripts
> . gettext.sh
Reverse that, put gettext scripts first so they do source the right
files.
> 2)
>
> #!/bin/sh
> if [ "$GETTEXT_PATH" ]; then
> GETTEXT="$GETTEXT_PATH"
> else
> GETTEXT="/usr/share/gettext/scripts/gettext.sh"
> fi
> . $GETTEXT
>
>
> note that i'm not advocating you immediately change this, as someone
> else pointed out this would break a lot of stuff. i am however
> saying that your "that which is not explicitly denied must be allowed"
> reasoning is flawed and is formed from your own bias to not have to
> inconvenience yourself.
>
>
> sean
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shell script sniplets in /usr/bin?
Santiago Vila <[EMAIL PROTECTED]> writes: > On Sun, 30 Jan 2005, sean finney wrote: > >> think about the purpose path is supposed to serve. the bash man page >> says PATH is "The search path for commands". it mentions nothing of >> shell scripts to be included/sourced. > > This is from bash(1): > > . filename [arguments] >source filename [arguments] > > Read and execute commands from filename in the current shell > environment and return the exit status of the last command executed > from filename. If filename does not contain a slash, filenames in > PATH are used to find the directory containing filename. The file > searched for in PATH need not be executable. > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] Another little thing on this: MULTIARCH Post sarge gettext base will have to be split into common data, architexture dependend libs and binaries: Package: gettext-base Architecture: any Multiarch: no Depends: gettext-base-common (= 1.2.3), gettext-base-libs (>= 1.2.3) Description: GNU Internationalization utilities for the base system Paclage: gettext-base-common Architecture: all Description: GNU Internationalization shared files for the base system Package: gettext-base-libs Architecture: any Multiarch: yes Description: GNU Internationalization shared libs for the base system Where do you want to put gettext.sh? Once in every gettext-base or only once in gettext-base-common? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shell script sniplets in /usr/bin?
On Sun, 30 Jan 2005, Goswin von Brederlow wrote: > Where do you want to put gettext.sh? Once in every gettext-base or > only once in gettext-base-common? I don't know, maybe in the same package as GNU.Gettext.dll :-) (which is to say: first things first, before that there will be C# support) Is there already an open policy proposal mandating multiarch? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shell script sniplets in /usr/bin?
Santiago Vila <[EMAIL PROTECTED]> writes: > On Sun, 30 Jan 2005, Goswin von Brederlow wrote: > >> Where do you want to put gettext.sh? Once in every gettext-base or >> only once in gettext-base-common? > > I don't know, maybe in the same package as GNU.Gettext.dll :-) > (which is to say: first things first, before that there will be C# support) > > Is there already an open policy proposal mandating multiarch? > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] There is a page with details linked in the debian-amd64 FAQ somewhere and there are a bunch of patches. All of them have been kept back so far till sarge is out of the way. After that the BTS will be hit by a wave. Debian/linux has been working on multiarch for over 5 years now I think and its high time to finaly do something about it. The current support is more than disapointing. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#268377: Bug#291939: Support for arch aliases (Was: Split System/Cpu for architecture handling)
On Tue, Jan 25, 2005 at 12:05:34AM -0200, Henrique de Moraes Holschuh wrote: > On Mon, 24 Jan 2005, Guillem Jover wrote: > > The idea is to introduce architecture aliases, they will only take > [...] > > > I've a added as well a new option (-n normalize) to dpkg-architecture > > so Maintainers can use it to get the alias expansions. Try it to see > > the results. > > The (only) problem I can see with this is that, should we add or remove a > new arch to an alias, you have to recompile everything to be completely in > sync. Ideally it should match with target system-cpu and not have a list of everything possible. See below. > This can be fixed by keeping the alias somewhere, instead of just expanding > it everywhere. Yes, well my implementation expands the aliases but only internally, you only get the relevant target dependencies when building. Also exposing the expansions (via -n) is not wise. I think a better implementation would be to just match the aliases the same way it's currently done with the "any" virtual arch. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
