[opensuse-factory] 'which' missing from 'base build root'
Hi all, What a nice surprise I had to see this morning: some 'old' package (last touched > 12 months ago) suddenly fails to build.. Builderror? -bash: which: command not found yes, right: which was split out into a sep. package. No consideration or pre-announcement was done (or I missed it). And to make the whole story fun: BuildRequires: which => unresolvable: nothing provides which great stuff! I think everybody would appreciate if such fundamental changes, if not handled transparently, would be communicated upfront. As a wrapup: the 'submit' came in with: https://build.opensuse.org/request/show/161218 The submitter added as submit text: "Please wait for which, adjtimex, time to go in first since those packages have been split from util-linux." * Are we (packagers) now supposed to add BuildRequires: which to whatever uses it (I don't object it.. but where does it stop?) * When can we expect 'which' to actually appear in Factory, so that builds are possible again? Best regards, Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
The best option is to use type instead of which. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sam, 2013-03-30 at 14:37 +0100, Andreas Schwab wrote:
The best option is to use type instead of which.
Whereas this might be very good for the user, it is close to no possible way to fix packages. There are a bunch of builds making use of 'which' to verify if a program exists on the system (might not be the best way.. but it's the way often used). Type is clearly good for interactive use.. but $(type ls) will not get you anywhere, whereas $(which ls) actually works (let's not discuss about usefulness of those commands.. they are just to show the point). Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Dimstar / Dominique Leuenberger <dimstar@opensuse.org> writes:
Type is clearly good for interactive use..
type is perfectly usable non-interactively as well.
but $(type ls) will not get you anywhere, whereas $(which ls) actually works
type -p is what you want. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sam, 2013-03-30 at 16:24 +0100, Andreas Schwab wrote:
Dimstar / Dominique Leuenberger <dimstar@opensuse.org> writes:
Type is clearly good for interactive use..
type is perfectly usable non-interactively as well.
but $(type ls) will not get you anywhere, whereas $(which ls) actually works
type -p is what you want.
Ok, learned something... yet, this implies changing a bunch of upstream projects autogen.sh, .m4 and other files, simply for the non-reasonable thing of removing (un-announced) which from the base build system. Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 03/30/2013 04:26 PM, Dimstar / Dominique Leuenberger wrote:
On Sam, 2013-03-30 at 16:24 +0100, Andreas Schwab wrote:
Dimstar / Dominique Leuenberger <dimstar@opensuse.org> writes:
Type is clearly good for interactive use..
type is perfectly usable non-interactively as well.
but $(type ls) will not get you anywhere, whereas $(which ls) actually works
type -p is what you want.
Ok, learned something...
yet, this implies changing a bunch of upstream projects autogen.sh, .m4 and other files, simply for the non-reasonable thing of removing (un-announced) which from the base build system.
Dominique, this was AFAIU not intented - neither by Jan as submitter nor by myself during the review. We both expected that this gets caught before checkin, Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Dimstar / Dominique Leuenberger wrote:
On Sam, 2013-03-30 at 16:24 +0100, Andreas Schwab wrote:
Dimstar / Dominique Leuenberger <dimstar@opensuse.org> writes:
but $(type ls) will not get you anywhere, whereas $(which ls) actually works type -p is what you want.
Ok, learned something... Dominique
It is probably better to use type -P if you are looking for the file on disk.. If there is an alias in place or a function in place i.e. something like: alias ls='ls -CF --show-control-chars --color=always' the lower case, "-p" will show a blank whereas "-P" (capital), forced a path search. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Quoting Linda Walsh <suse@tlinx.org>:
Dimstar / Dominique Leuenberger wrote:
On Sam, 2013-03-30 at 16:24 +0100, Andreas Schwab wrote:
Dimstar / Dominique Leuenberger <dimstar@opensuse.org> writes:
but $(type ls) will not get you anywhere, whereas $(which ls) actually works type -p is what you want.
Ok, learned something... Dominique
It is probably better to use type -P if you are looking for the file on disk..
If there is an alias in place or a function in place i.e. something like:
alias ls='ls -CF --show-control-chars --color=always'
the lower case, "-p" will show a blank whereas "-P" (capital), forced a path search.
Which still does not change the fact that a lot of build scripts use which.. Changing all the scritps / build systems to do "the right thing" will not be done in the next 2 weeks. in plus: the issue has been fixed and everybody moved on to breaking other stuff :) Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Andreas Schwab <schwab@suse.de> [2013-03-30 16:24]:
Dimstar / Dominique Leuenberger <dimstar@opensuse.org> writes:
Type is clearly good for interactive use..
type is perfectly usable non-interactively as well.
but $(type ls) will not get you anywhere, whereas $(which ls) actually works
type -p is what you want.
No, it isn't, you want "command -v". In contrast to the "type" bashism, it is specified by POSIX, implemented as a regular builtin in all Bourne-derived shells present in Factory, and perfectly capable of covering the most common use-case of "which", namely printing the pathname of the given utility while taking PATH into account. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 30.03.2013 16:44, schrieb Guido Berhoerster:
* Andreas Schwab <schwab@suse.de> [2013-03-30 16:24]:
type -p is what you want.
No, it isn't, you want "command -v". In contrast to the "type" bashism, it is specified by POSIX, implemented as a regular builtin in all Bourne-derived shells present in Factory, and perfectly capable of covering the most common use-case of "which", namely printing the pathname of the given utility while taking PATH into account.
But both are not equivalent to "which": seife@susi:~> which ls /usr/bin/ls seife@susi:~> type -p ls seife@susi:~> command -v ls alias ls='ls $LS_OPTIONS' seife@susi:~> -- Stefan Seyfried "If your lighter runs out of fluid or flint and stops making fire, and you can't be bothered to figure out about lighter fluid or flint, that is not Zippo's fault." -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Stefan Seyfried <stefan.seyfried@googlemail.com> [2013-03-30 16:57]:
Am 30.03.2013 16:44, schrieb Guido Berhoerster:
* Andreas Schwab <schwab@suse.de> [2013-03-30 16:24]:
type -p is what you want.
No, it isn't, you want "command -v". In contrast to the "type" bashism, it is specified by POSIX, implemented as a regular builtin in all Bourne-derived shells present in Factory, and perfectly capable of covering the most common use-case of "which", namely printing the pathname of the given utility while taking PATH into account.
But both are not equivalent to "which":
seife@susi:~> which ls /usr/bin/ls seife@susi:~> type -p ls seife@susi:~> command -v ls alias ls='ls $LS_OPTIONS'
That is no relevant for script use since there are no aliases in a non-interactive shell. And in case of regular and special builtins as well as functions which shadow utilities in PATH, the name of the builtin/function will be printed back. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Guido Berhoerster wrote:
* Stefan Seyfried <stefan.seyfried@googlemail.com> [2013-03-30 16:57]:
Am 30.03.2013 16:44, schrieb Guido Berhoerster:
type -p is what you want. No, it isn't, you want "command -v". In contrast to the "type" bashism, it is specified by POSIX, implemented as a regular builtin in all Bourne-derived shells present in Factory, and
* Andreas Schwab <schwab@suse.de> [2013-03-30 16:24]: perfectly capable of covering the most common use-case of "which", namely printing the pathname of the given utility while taking PATH into account. But both are not equivalent to "which":
seife@susi:~> which ls /usr/bin/ls seife@susi:~> type -p ls seife@susi:~> command -v ls alias ls='ls $LS_OPTIONS'
That is no relevant for script use since there are no aliases in a non-interactive shell.
Unless a caller turned them on: shopt While most of my shopts are only for interactive shells, expand_aliases is too useful in programming in bash to let go. So I have: shopt -s expand_aliases if [ -n "$_sh_interactive_shell" ] ; then if [[ "$BASH_VERSINFO" == '4' ]]; then shopt -s globstar dirspell autocd fi set -o pipefail shopt -s nocaseglob nocasematch expand_aliases shopt -s cdable_vars cdspell checkhash checkwinsize cmdhist dotglob extglob shopt -s histappend histverify hostcomplete lithist histreedit shopt -s no_empty_cmd_completion xpg_echo called from my bashrc, and bash_env I define aliases for keywords like: alias int='declare -i'
int i=1 i+=2 #note, if you don't dcl i an int first, you get string concatenation echo $i 3
comand -v with a function will just give the funcname, not the path there is no way to list the path using the POSIX util. POSIX is lowest common denominator. Back in the 11.x timeframe, you could safely delete a directory contents but not the directory by (cd <dir> && rm -fr --one-filesystem .) There is no other easy expression of that idiom. So POSIX removed it, on the grounds that BSD had it in to protect their students from accidently deleting all files on similar reasoning to the default disabling of rm -fr /. But they are very different. if you try it with the name, depending on the version of coreutils you run, different syntaxes operate differently if the directory name is a symlink. wild cards are out as they can start on start on a submount and delete it too and bash's ** expansion doesn't have an option to stay on 1 file system. You'd have to use 'find' to reconstruct the same behavior they removed to protect the children. rm has to do a depth first traversal when doing a delete, but has a special exception added to inspect the top directory first and if it ".", then abort the normal traveral (with -f suppressing any error messages about not being able to delete ".". Don't suppse suse would want a patch fixing that....so it's useful again... I happen to have one available for some reason or another... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Guido Berhoerster wrote:
No, it isn't, you want "command -v". In contrast to the "type" bashism, it is specified by POSIX,
Similar comment on command as on type -- command -v is to list back how the command will be interpreted, not to hand back a path or get to the path. There is no document way with command to list the path if there is an alias or function in place. However you can bypass the alias/function and call the command by using the -p switch, i.e.: "command -p prog" But, that doesn't give you the pathname. I.e. if you want the path, use "type -P" in bash. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Saturday 2013-03-30 16:24, Andreas Schwab wrote:
Dimstar / Dominique Leuenberger <dimstar@opensuse.org> writes:
Type is clearly good for interactive use..
type is perfectly usable non-interactively as well.
but $(type ls) will not get you anywhere, whereas $(which ls) actually works
type -p is what you want.
It is not. If "ls" is an alias, `type -p ls` will return nothing, while `which ls` continues to yield the path to the program. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Jan Engelhardt <jengelh@inai.de> writes:
It is not. If "ls" is an alias, `type -p ls` will return nothing, while `which ls` continues to yield the path to the program.
A noninteractive shell has no aliases. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Andreas Schwab wrote:
Jan Engelhardt <jengelh@inai.de> writes:
It is not. If "ls" is an alias, `type -p ls` will return nothing, while `which ls` continues to yield the path to the program.
A noninteractive shell has no aliases.
I even have some I save and propagate in the ENV to children
Andreas.
Mind do. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Saturday 2013-03-30 13:18, Dimstar / Dominique Leuenberger wrote:
As a wrapup: the 'submit' came in with: https://build.opensuse.org/request/show/161218
The submitter added as submit text: "Please wait for which, adjtimex, time to go in first since those packages have been split from util-linux."
Hm that would suggest that reviewers don't read the message..
* Are we (packagers) now supposed to add BuildRequires: which to whatever uses it (I don't object it.. but where does it stop?)
IMO, a Support: entry should be added to the prjconfs of Base:System and openSUSE:Factory. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sam, 2013-03-30 at 14:44 +0100, Jan Engelhardt wrote:
On Saturday 2013-03-30 13:18, Dimstar / Dominique Leuenberger wrote:
As a wrapup: the 'submit' came in with: https://build.opensuse.org/request/show/161218
The submitter added as submit text: "Please wait for which, adjtimex, time to go in first since those packages have been split from util-linux."
Hm that would suggest that reviewers don't read the message..
Reviewers do.. but 'checkiners' don't :) which is currently pending legal review as it seems... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 03/30/2013 02:44 PM, Jan Engelhardt wrote:
On Saturday 2013-03-30 13:18, Dimstar / Dominique Leuenberger wrote:
As a wrapup: the 'submit' came in with: https://build.opensuse.org/request/show/161218
The submitter added as submit text: "Please wait for which, adjtimex, time to go in first since those packages have been split from util-linux."
Hm that would suggest that reviewers don't read the message..
That message was added during review ;), seems Coolo did not read it,
* Are we (packagers) now supposed to add BuildRequires: which to whatever uses it (I don't object it.. but where does it stop?)
IMO, a Support: entry should be added to the prjconfs of Base:System and openSUSE:Factory.
And to the patterns - let's wait until next week for Coolo to do this change, Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 30.03.2013 14:44, Jan Engelhardt wrote:
On Saturday 2013-03-30 13:18, Dimstar / Dominique Leuenberger wrote:
As a wrapup: the 'submit' came in with: https://build.opensuse.org/request/show/161218
The submitter added as submit text: "Please wait for which, adjtimex, time to go in first since those packages have been split from util-linux."
Hm that would suggest that reviewers don't read the message..
The reviewers read it, but if they pass the review, the checkin is going almost unintended.
* Are we (packagers) now supposed to add BuildRequires: which to whatever uses it (I don't object it.. but where does it stop?)
IMO, a Support: entry should be added to the prjconfs of Base:System and openSUSE:Factory.
No. But I already submitted a rpm-build package that requires which, but as which is still in legal-team review, I had to actually ignore the dependency Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 03/30/2013 01:18 PM, Dimstar / Dominique Leuenberger wrote:
Hi all,
What a nice surprise I had to see this morning: some 'old' package (last touched > 12 months ago) suddenly fails to build..
Builderror? -bash: which: command not found
yes, right: which was split out into a sep. package. No consideration or pre-announcement was done (or I missed it).
And to make the whole story fun: BuildRequires: which
=> unresolvable: nothing provides which
great stuff!
I think everybody would appreciate if such fundamental changes, if not handled transparently, would be communicated upfront.
As a wrapup: the 'submit' came in with: https://build.opensuse.org/request/show/161218
The submitter added as submit text: "Please wait for which, adjtimex, time to go in first since those packages have been split from util-linux."
* Are we (packagers) now supposed to add BuildRequires: which to whatever uses it (I don't object it.. but where does it stop?)
* When can we expect 'which' to actually appear in Factory, so that builds are possible again?
AFAIK which is still in the legal queue, let's wait until Coolo and Ciaran are back from Easter to resolve this, Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (9)
-
Andreas Jaeger -
Andreas Schwab -
Dimstar / Dominique Leuenberger -
Dominique Leuenberger a.k.a. Dimstar
-
Guido Berhoerster -
Jan Engelhardt -
Linda Walsh -
Stefan Seyfried -
Stephan Kulow