|
Home > Archive > Debian Developers > June 2004 > Pre-Depends of #CDD#-common meta packages from cdd-common
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Pre-Depends of #CDD#-common meta packages from cdd-common
|
|
| Andreas Tille 2004-06-11, 6:30 pm |
| Hi,
I'm currently trying to fix some configuration issues which occure with
the med-common meta package which will also influence all other CDDs
which will use cdd-dev to build their meta packages. The problem is as
follows: If the CDD uses the user-role based menu system this should
be configured via debconf in the configuration script of the #CDD#-common
package (where #CDD# stands for jr, med, np, edu, ...). This means
that the cdd-common package has to be configured *before* the #CDD#-common
package is installed, because /etc/cdd/cdd.conf has to be read and
the tools in /usr/share/cdd/ have to be available. Then the type of
the role system (currently only UNIX-groups but we know that this
might change in the future) has to be selected. IMHO that's why we
need a Pre-Depends from cdd-common which has to be discussed on
debian-devel.
What do you think about it?
Kind regards
Andreas.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Colin Watson 2004-06-11, 6:30 pm |
| On Fri, Jun 11, 2004 at 11:20:52AM +0200, Andreas Tille wrote:
> I'm currently trying to fix some configuration issues which occure with
> the med-common meta package which will also influence all other CDDs
> which will use cdd-dev to build their meta packages. The problem is as
> follows: If the CDD uses the user-role based menu system this should
> be configured via debconf in the configuration script of the #CDD#-common
> package (where #CDD# stands for jr, med, np, edu, ...). This means
> that the cdd-common package has to be configured *before* the #CDD#-common
> package is installed, because /etc/cdd/cdd.conf has to be read and
> the tools in /usr/share/cdd/ have to be available. Then the type of
> the role system (currently only UNIX-groups but we know that this
> might change in the future) has to be selected. IMHO that's why we
> need a Pre-Depends from cdd-common which has to be discussed on
> debian-devel.
I'm not sure I quite understand what's going on here, but it seems to me
that you have one or the other of these cases:
* meta-package's .config script requires data from cdd-common
Answer: You can't. .config scripts can only depend on Essential
packages plus debconf, and Pre-Depends doesn't help.
* meta-package's .postinst script requires data from cdd-common
Answer: Use Depends, which is sufficient.
The only reason you should need Pre-Depends is if the meta-package's
..preinst script requires data from cdd-common.
Does this make sense?
--
Colin Watson [cjwatson@flatline.org.uk]
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Andreas Tille 2004-06-11, 6:30 pm |
| On Fri, 11 Jun 2004, Colin Watson wrote:
> * meta-package's .config script requires data from cdd-common
Yes.
> Answer: You can't. .config scripts can only depend on Essential
> packages plus debconf, and Pre-Depends doesn't help.
>
> * meta-package's .postinst script requires data from cdd-common
>
> Answer: Use Depends, which is sufficient.
This was the old solution which is suboptimal because asking questions
in postinst script sucks. The question can only be asked when cdd-common
is installed because they call scripts from this package to aquire data
which are needed for the questions. Would you go with this solution
and write a lintian.override to declare that this is intended?
> The only reason you should need Pre-Depends is if the meta-package's
> .preinst script requires data from cdd-common.
>
> Does this make sense?
Yes. It means that I have to stick to the solution I found before and
there seems to be no way to enhance the situation.
Kind regards
Andreas.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Ben Armstrong 2004-06-11, 6:30 pm |
| | |
| Steve Langasek 2004-06-11, 6:30 pm |
| On Fri, Jun 11, 2004 at 12:59:04PM +0200, Andreas Tille wrote:
> On Fri, 11 Jun 2004, Colin Watson wrote:
> Yes.
[vbcol=seagreen]
[vbcol=seagreen]
> This was the old solution which is suboptimal because asking questions
> in postinst script sucks. The question can only be asked when cdd-common
> is installed because they call scripts from this package to aquire data
> which are needed for the questions.
The .config script is executed twice during an apt-based package
installation: once during pre-configure, and once when the postinst
runs.
If you write your .config script carefully, you can make it run
correctly in the absence of the packages you need, but use them if
they're present. This maximizes the number of people who will be able
to take advantage of pre-config for your package.
--
Steve Langasek
postmodern programmer
| |
| Frank Küster 2004-06-11, 6:30 pm |
| Steve Langasek <vorlon@debian.org> wrote:
> On Fri, Jun 11, 2004 at 12:59:04PM +0200, Andreas Tille wrote:
>
> The .config script is executed twice during an apt-based package
> installation: once during pre-configure, and once when the postinst
> runs.
>
> If you write your .config script carefully, you can make it run
> correctly in the absence of the packages you need, but use them if
> they're present. This maximizes the number of people who will be able
> to take advantage of pre-config for your package.
In this particular case, wouldn't it be possible to defer any
questioning in config if the needed commands are not available?
if command $NEEDED_COMMAND >/dev/null 2>&1; then
db_input ...
else
# wait until we are called again from postinst,=20
# then the command will be available
fi
(besides that I don't know whether "command" is a bashism)
Regards, Frank
--=20
Frank K=FCster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie
| |
| Colin Watson 2004-06-11, 6:30 pm |
| On Fri, Jun 11, 2004 at 05:50:44PM +0200, Frank Küster wrote:
> In this particular case, wouldn't it be possible to defer any
> questioning in config if the needed commands are not available?
>
> if command $NEEDED_COMMAND >/dev/null 2>&1; then
> db_input ...
> else
> # wait until we are called again from postinst,
> # then the command will be available
> fi
>
> (besides that I don't know whether "command" is a bashism)
I think you might have wanted 'command -v', and that's indeed not
portable. base-passwd.postinst does this:
# A cut-down version of 'which' from debianutils.
searchpath () {
PROGRAM="$1"
IFS_SAVE="$IFS"
IFS=:
RET=1
for ELEMENT in $PATH; do
if [ -z "$ELEMENT" ]; then
ELEMENT=.
fi
if [ -f "$ELEMENT/$PROGRAM" ] && \
[ -x "$ELEMENT/$PROGRAM" ]; then
RET=0
break
fi
done
IFS="$IFS_SAVE"
return "$RET"
}
....
if searchpath nscd; then ...; fi
--
Colin Watson [cjwatson@flatline.org.uk]
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Andreas Tille 2004-06-11, 6:30 pm |
| On Fri, 11 Jun 2004, Steve Langasek wrote:
> The .config script is executed twice during an apt-based package
> installation: once during pre-configure, and once when the postinst
> runs.
>
> If you write your .config script carefully, you can make it run
> correctly in the absence of the packages you need, but use them if
> they're present. This maximizes the number of people who will be able
> to take advantage of pre-config for your package.
Ahhh, this is a pretty good hint. "Write it right" means: check first
if the tools are present and run the stuff which runs. May be I have
to "touch /var/tmp/pkg.just-configured" to set a marker for the second
call, should I?
Any example packages to steal code and make sure I understand right?
Kind regards
Andreas.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Andreas Tille 2004-06-11, 6:30 pm |
| On Fri, 11 Jun 2004, Colin Watson wrote:
> I think you might have wanted 'command -v', and that's indeed not
> portable. base-passwd.postinst does this:
>
> # A cut-down version of 'which' from debianutils.
Hmmm, which is part of debianutils which is required. Why do I
have to work around this?
Kind regards
Andreas.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Andreas Tille 2004-06-11, 6:30 pm |
| On Fri, 11 Jun 2004, Ben Armstrong wrote:
> On Fri, 2004-06-11 at 07:59, Andreas Tille wrote:
>
> Andreas, please remind me why the .config script needs to use cdd-common
> tools and /etc/cdd/cdd.conf, instead of just asking questions and
> deferring any work to be run in the .postinst.
One question is which users should be in the role CDD-user. To
ask this question we need to know which Role system to use and
need the tools which query the right user role system. This is
contained in cdd-common.
Kind regards
Andreas.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Colin Watson 2004-06-11, 6:30 pm |
| On Fri, Jun 11, 2004 at 07:31:16PM +0200, Andreas Tille wrote:
> On Fri, 11 Jun 2004, Colin Watson wrote:
>
> Hmmm, which is part of debianutils which is required. Why do I
> have to work around this?
You didn't read the patch in detail. (It does *not* use 'which'; it
reimplements it in pure shell. 'which' isn't reliably-enough portable.)
Cheers,
--
Colin Watson [cjwatson@flatline.org.uk]
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Steve Langasek 2004-06-11, 6:39 pm |
| On Fri, Jun 11, 2004 at 07:26:58PM +0200, Andreas Tille wrote:
[vbcol=seagreen]
> Ahhh, this is a pretty good hint. "Write it right" means: check first
> if the tools are present and run the stuff which runs. May be I have
> to "touch /var/tmp/pkg.just-configured" to set a marker for the second
> call, should I?
Usually not; you should still be able to reconfigure the package with
dpkg-reconfigure, and the scripts must be idempotent, so as long as you
write for this there's rarely any reason to need state files to track
whether the config script has done anything before. (And /var/tmp would
be the wrong place -- you'd need to store this in /var/lib.)
> Any example packages to steal code and make sure I understand right?
Well, the libct1 package uses the same kind of check in a preinst, but
this is probably a bad example because 1) it's in the preinst rather
than the config, and 2) it does need a separate state file to prevent
running a certain command twice. ;)
--
Steve Langasek
postmodern programmer
| |
| Joey Hess 2004-06-11, 7:03 pm |
| Steve Langasek wrote:
> The .config script is executed twice during an apt-based package
> installation: once during pre-configure, and once when the postinst
> runs.
>
> If you write your .config script carefully, you can make it run
> correctly in the absence of the packages you need, but use them if
> they're present. This maximizes the number of people who will be able
> to take advantage of pre-config for your package.
I would advise against doing this, it will just make things harder or
break if/when debconf is fixed to not run config scripts twice.
--
see shy jo
| |
| Joey Hess 2004-06-12, 2:49 am |
| Steve Langasek wrote:
> The .config script is executed twice during an apt-based package
> installation: once during pre-configure, and once when the postinst
> runs.
>
> If you write your .config script carefully, you can make it run
> correctly in the absence of the packages you need, but use them if
> they're present. This maximizes the number of people who will be able
> to take advantage of pre-config for your package.
I would advise against doing this, it will just make things harder or
break if/when debconf is fixed to not run config scripts twice.
--
see shy jo
| |
| Wouter Verhelst 2004-06-12, 2:49 am |
| On Fri, Jun 11, 2004 at 05:50:44PM +0200, Frank Küster wrote:
> (besides that I don't know whether "command" is a bashism)
Doesn't matter.
* You can use which(1), which is part of debianutils, an Essential
package, and which should be portable.
* bash, itself, is an Essential package, so you could just
s:#!/bin/sh:#!/bin/bash: and not care about portability.
--
EARTH
smog | bricks
AIR -- mud -- FIRE
soda water | tequila
WATER
-- with thanks to fortune
| |
| David Weinehall 2004-06-12, 11:51 pm |
| On Sat, Jun 12, 2004 at 07:14:47AM +0200, Wouter Verhelst wrote:
> On Fri, Jun 11, 2004 at 05:50:44PM +0200, Frank Küster wrote:
(yes, it is)
[vbcol=seagreen]
> Doesn't matter.
>
> * You can use which(1), which is part of debianutils, an Essential
> package, and which should be portable.
Probably the best solution. which should probably be moved from
/usr/bin/which to /bin/which, though.
> * bash, itself, is an Essential package, so you could just
> s:#!/bin/sh:#!/bin/bash: and not care about portability.
Please don't. I'm doing my best to rid all sh-scripts from
XSI:isms, bashisms, cshisms, etc... And having the scripts just
dodge the bullet by using /bin/bash instead kind of defeats this
idea. I've already cleaned up a large portion of base, and begun
trickling these change, in a very low tempo, back into those package.
My goal is of course to be able to just equiv away bash on a minimal
system and without anything breaking. (And yes, I know that this will
of course not continue to work if I install packages from outside of
base, but that's outside of the scope of my current effort.)
Note that I'm not modifying build-scripts; I have bash on all my
build-machines anyway (it's my shell of preference, so why should I?),
but being able to replace bash with posh on a minimal installation to
save 1MB of diskspace, would make quite a difference for an embedded
computer.
Besides, ridding the scripts of things such as these also increases
portability to those crippled non-Debian systems out there. Not all of
them use bash.
Of course, packages outside of base aren't equally prioritised and
could live on happily ever after with bash-scripts, but I do think that
avoiding bash-scripts would be best anyway, since it's really quite
simple to avoid them in most cases. And when the bashisms are a bit
harder to dodge, I'll do my best to help. =)
Obviously, I don't expect to have the changes merged before the
release of Sarge (even though I would certainly not mind having the
work done; just keeping the patches up to date separately should be
easy enough.)
BTW: Anyone interested in helping me with this, chime up.
Regards: David Weinehall
--
/) David Weinehall <tao@acc.umu.se> /) Northern lights wander (\
// Maintainer of the v2.0 kernel // Dance across the winter sky //
\) http://www.acc.umu.se/~tao/ (/ Full colour fire (/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Andrew Suffield 2004-06-12, 11:51 pm |
| On Sat, Jun 12, 2004 at 09:40:06AM +0200, David Weinehall wrote:
>
> Please don't.
Please do. Replacing adequete languages with less flexible ones for
*no reason* is stupid.
Might as well say "I want all shell scripts in Debian to also be valid
php scripts", it'd be about as useful.
--
.''`. ** Debian GNU/Linux ** | Andrew Suffield
: :' : http://www.debian.org/ |
`. `' |
`- -><- |
| |
| David Weinehall 2004-06-12, 11:51 pm |
| On Sat, Jun 12, 2004 at 11:52:01AM +0100, Andrew Suffield wrote:
> On Sat, Jun 12, 2004 at 09:40:06AM +0200, David Weinehall wrote:
>
> Please do. Replacing adequete languages with less flexible ones for
> *no reason* is stupid.
Ahhh, but you conveniently snipped the reasons I provided. And using
bashisms for *no reason* is far more stupid...
> Might as well say "I want all shell scripts in Debian to also be valid
> php scripts", it'd be about as useful.
Making things php-scripts would hardly free up disk space for a minimal
system, now would it? You could've at least suggested perl, since
perl-base is essential...
Anyway, I wasn't talking about exchanging about earth-shattering changes
that totally changes the way the script works. We're talking about
removing one bashism in a script to make it more portable, allow it to
meet policy, and in the end allow drop-in replacement of smaller foot-print
shells instead of bash,
Regards: David Weinehall
--
/) David Weinehall <tao@acc.umu.se> /) Northern lights wander (\
// Maintainer of the v2.0 kernel // Dance across the winter sky //
\) http://www.acc.umu.se/~tao/ (/ Full colour fire (/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Andreas Tille 2004-06-12, 11:51 pm |
| On Fri, 11 Jun 2004, Colin Watson wrote:
>
> You didn't read the patch in detail. (It does *not* use 'which'; it
Well, I read it in detail and wondered *why* it does *not* use which
if which is available.
> reimplements it in pure shell. 'which' isn't reliably-enough portable.)
This is what I do not understand: In how far is which not portable?
Kind regards
Andreas.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Andrew Suffield 2004-06-12, 11:51 pm |
| On Sat, Jun 12, 2004 at 04:25:28PM +0200, David Weinehall wrote:
> On Sat, Jun 12, 2004 at 11:52:01AM +0100, Andrew Suffield wrote:
>
> Ahhh, but you conveniently snipped the reasons I provided.
You didn't give any, except the bogus "portability" one.
> And using
> bashisms for *no reason* is far more stupid...
No, "doing nothing", absent any reason to do something, is the
sensible approach.
> We're talking about
> removing one bashism in a script to make it more portable
^^^^^^^^^^^^^^^^^^^^^
False. Please come back when you have some comprehension of what
portable shell scripting means. There's a chapter in the autoconf
manual that might clue you in.
The only platform where /bin/sh is "reliably" a posix shell is
Debian. Deal with it.
> allow it to
> meet policy,
False dilemma; more trivially accomplished by using #!/bin/bash.
> and in the end allow drop-in replacement of smaller foot-print
> shells instead of bash,
Handwaving.
Please stop this pointless crusade against bash. All it can accomplish
is to introduce bugs where previously there were none. Throwing around
words like "portability" does not accomplish anything.
--
.''`. ** Debian GNU/Linux ** | Andrew Suffield
: :' : http://www.debian.org/ |
`. `' |
`- -><- |
| |
| David Weinehall 2004-06-12, 11:51 pm |
| On Sat, Jun 12, 2004 at 06:47:11PM +0100, Andrew Suffield wrote:
> On Sat, Jun 12, 2004 at 04:25:28PM +0200, David Weinehall wrote:
>
> You didn't give any, except the bogus "portability" one.
You might regard it as a bogus reason, I sure don't.
I did also mention the storage-space issue, but since you neatly removed
it with your first reply to me, I've repeated it below.
>
> No, "doing nothing", absent any reason to do something, is the
> sensible approach.
Sigh. I have provided sufficient reasons to do something. And
substituting /bin/sh for /bin/bash is doing something as well.
In both cases we're talking about a single substitution.
> ^^^^^^^^^^^^^^^^^^^^^
> False. Please come back when you have some comprehension of what
> portable shell scripting means. There's a chapter in the autoconf
> manual that might clue you in.
There's portable, then there's portable. Being portable to still
developed platforms is reasonable, being portable to Unixen from 1977 is
not.
However, I do not mind at all people writing scripts that cater to old
quirks of semi-extinct platforms, but I do not think it's needed for
maintainer-scripts.
> The only platform where /bin/sh is "reliably" a posix shell is
> Debian. Deal with it.
>
>
> False dilemma; more trivially accomplished by using #!/bin/bash.
Yeah, oh the horrors of having to replace command -v with which instead
of sh with bash... Oh so much less trivial.
>
> Handwaving.
Far from handwaving. (In fact, I try to keep at least my right hand
very immobile at the moment, due to just managing to cut two of my
fingertips when slicing a lime...) I have a very specific use for this,
described below (and described in my original message, which you so
neatly trimmed down)...
> Please stop this pointless crusade against bash. All it can accomplish
> is to introduce bugs where previously there were none. Throwing around
> words like "portability" does not accomplish anything.
It is *NOT* a crusade against bash. I use bash as my primary shell for
all my workstations, my laptop, and my server (and my MacOS X-machine).
I'd rather be able to avoid having it installed on my embedded machine,
though. 1MB of storage doesn't matter squat on my 40GB drive on my
laptop, but it's a 32nd of the total space on my embedded device.
And I bet other Debian-developers and users trying to fit something onto
tight devices wouldn't mind either.
Regards: David Weinehall
--
/) David Weinehall <tao@acc.umu.se> /) Northern lights wander (\
// Maintainer of the v2.0 kernel // Dance across the winter sky //
\) http://www.acc.umu.se/~tao/ (/ Full colour fire (/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Andrew Suffield 2004-06-12, 11:51 pm |
| On Sat, Jun 12, 2004 at 08:21:17PM +0200, David Weinehall wrote:
>
> There's portable, then there's portable. Being portable to still
> developed platforms is reasonable, being portable to Unixen from 1977 is
> not.
Then what are you trying to accomplish? All of those platforms have
bash available. If those are the only ones you are interested in, bash
is *already* perfectly portable, so there's no gain to be had.
>
> It is *NOT* a crusade against bash. I use bash as my primary shell for
> all my workstations, my laptop, and my server (and my MacOS X-machine).
> I'd rather be able to avoid having it installed on my embedded machine,
> though. 1MB of storage doesn't matter squat on my 40GB drive on my
> laptop, but it's a 32nd of the total space on my embedded device.
It's 600k in the package, or 300k if you build it without all the
extra extensions for interactive use. You're going to have a hard time
finding a smaller shell than that, without simply farming out all the
functionality into other programs (which is counter-productive), and
it's a waste of time anyway when there are invariably much larger
things that can be tackled.
--
.''`. ** Debian GNU/Linux ** | Andrew Suffield
: :' : http://www.debian.org/ |
`. `' |
`- -><- |
| |
| David Weinehall 2004-06-12, 11:51 pm |
| On Sat, Jun 12, 2004 at 08:22:45PM +0100, Andrew Suffield wrote:
> On Sat, Jun 12, 2004 at 08:21:17PM +0200, David Weinehall wrote:
>
> Then what are you trying to accomplish? All of those platforms have
> bash available. If those are the only ones you are interested in, bash
> is *already* perfectly portable, so there's no gain to be had.
True. However, not all admins of other OS's share the opinion that bash
is a shell that should be installed on all systems...
>
> It's 600k in the package, or 300k if you build it without all the
> extra extensions for interactive use. You're going to have a hard time
> finding a smaller shell than that, without simply farming out all the
> functionality into other programs (which is counter-productive), and
> it's a waste of time anyway when there are invariably much larger
> things that can be tackled.
I don't have a hard time at all. posh, for instance, is much smaller
than that (103k) and POSIX-compliant, dash is 84k (has had some
compliance-bugs, but is getting pretty close now), and busybox-cvs is
138k (don't know how POSIX-compliant it is, though).
Of course, they are not really what you would choose as your favourite
shell for interactive use, but for embedded devices you seldom use the
shell except for scripts.
I'm working on tackling other things as well. Something has to be done
first though, and these changes are all small and non-intrusive, so it's
a good place to start. Most other changes to minimise disk and/or
memory-usage are far more intrusive. I cannot possibly see why you
oppose changing things not to rely on bashisms, considering that I have
promised to provide patches for all packages in base if needs be.
You may think it's a time-consuming task, but it won't consume *your* time
(well, except for the time you spend arguing here...), it's not going to
prevent you from having bash as your favourite shell, nor is it going to
prevent you from having /bin/sh as a symlink to /bin/bash.
Regards: David Weinehall
--
/) David Weinehall <tao@acc.umu.se> /) Northern lights wander (\
// Maintainer of the v2.0 kernel // Dance across the winter sky //
\) http://www.acc.umu.se/~tao/ (/ Full colour fire (/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Colin Watson 2004-06-13, 5:51 pm |
| On Sat, Jun 12, 2004 at 06:03:46PM +0200, Andreas Tille wrote:
> On Fri, 11 Jun 2004, Colin Watson wrote:
>
>
> Well, I read it in detail and wondered *why* it does *not* use which
> if which is available.
>
>
> This is what I do not understand: In how far is which not portable?
'which' is fine for interactive use, but if you try to use it in a
variety of shells and on a variety of operating systems you'll find that
its output and even sometimes its exit code vary too wildly for reliable
use in scripts. I used to use 'which' in a .bashrc shared across a
number of operating systems, and the astonishing variety of breakage
(even on some Linux distributions) was why I wrote a pure-Bourne-shell
version for myself and routinely avoid the command nowadays.
I guess in debian/postinst you can probably get away without worrying
about this, but I generally prefer portable shell wherever possible, by
way of good practice if nothing else. Of course, base-passwd.postinst
has special requirements because it's part of an Essential package, so
keeping dependencies to an absolute minimum is more valuable there.
Cheers,
--
Colin Watson [cjwatson@flatline.org.uk]
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| David Weinehall 2004-06-13, 5:51 pm |
| On Sun, Jun 13, 2004 at 12:39:11PM +0100, Colin Watson wrote:
> On Sat, Jun 12, 2004 at 06:03:46PM +0200, Andreas Tille wrote:
>
> 'which' is fine for interactive use, but if you try to use it in a
> variety of shells and on a variety of operating systems you'll find that
> its output and even sometimes its exit code vary too wildly for reliable
> use in scripts. I used to use 'which' in a .bashrc shared across a
> number of operating systems, and the astonishing variety of breakage
> (even on some Linux distributions) was why I wrote a pure-Bourne-shell
> version for myself and routinely avoid the command nowadays.
>
> I guess in debian/postinst you can probably get away without worrying
> about this, but I generally prefer portable shell wherever possible, by
> way of good practice if nothing else. Of course, base-passwd.postinst
> has special requirements because it's part of an Essential package, so
> keeping dependencies to an absolute minimum is more valuable there.
Wouldn't it be a good thing to move which from debianutils to
/bin/which. debianutils is essential/required/base, so it should meet
various availability-requirements and minimum-dependency requirements.
Regards: David Weinehall
--
/) David Weinehall <tao@acc.umu.se> /) Northern lights wander (\
// Maintainer of the v2.0 kernel // Dance across the winter sky //
\) http://www.acc.umu.se/~tao/ (/ Full colour fire (/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Colin Watson 2004-06-13, 5:51 pm |
| On Sun, Jun 13, 2004 at 01:49:38PM +0200, David Weinehall wrote:
> On Sun, Jun 13, 2004 at 12:39:11PM +0100, Colin Watson wrote:
>
> Wouldn't it be a good thing to move which from debianutils to
> /bin/which.
Like I say, I believe it should be for interactive use only, so I don't
really care that it's in /usr. Call me a purist if you like ...
The searchpath() example I gave is a simple cut-and-paste shell
function, and actually makes code neater - no messy redirections needed.
> debianutils is essential/required/base, so it should meet
> various availability-requirements and minimum-dependency requirements.
I would still prefer not to rely on it from other Essential packages.
The consequences of adding extra dependency edges there can be
surprising at times, and it is always a win to keep Essential as
reliable as possible. (Also, some older versions of debianutils managed
'which' using alternatives ...)
Cheers,
--
Colin Watson [cjwatson@flatline.org.uk]
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| David Weinehall 2004-06-13, 5:51 pm |
| On Sun, Jun 13, 2004 at 12:59:53PM +0100, Colin Watson wrote:
> On Sun, Jun 13, 2004 at 01:49:38PM +0200, David Weinehall wrote:
>
> Like I say, I believe it should be for interactive use only, so I don't
> really care that it's in /usr. Call me a purist if you like ...
>
> The searchpath() example I gave is a simple cut-and-paste shell
> function, and actually makes code neater - no messy redirections needed.
>
>
> I would still prefer not to rely on it from other Essential packages.
> The consequences of adding extra dependency edges there can be
> surprising at times, and it is always a win to keep Essential as
> reliable as possible. (Also, some older versions of debianutils managed
> 'which' using alternatives ...)
Fair enough. It'll make my work a bit messier though... =)
Regards: David
--
/) David Weinehall <tao@acc.umu.se> /) Northern lights wander (\
// Maintainer of the v2.0 kernel // Dance across the winter sky //
\) http://www.acc.umu.se/~tao/ (/ Full colour fire (/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Clint Adams 2004-06-13, 5:51 pm |
| > Like I say, I believe it should be for interactive use only, so I don't
> really care that it's in /usr. Call me a purist if you like ...
I'm curious; in which situations do you believe it to be useful for
interactive use?
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Colin Watson 2004-06-13, 5:51 pm |
| On Sun, Jun 13, 2004 at 02:26:15PM -0400, Clint Adams wrote:
>
> I'm curious; in which situations do you believe it to be useful for
> interactive use?
"Where does this executable live on this system?" May not be perfect,
but it's generally good enough for what I want.
--
Colin Watson [cjwatson@flatline.org.uk]
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Clint Adams 2004-06-14, 5:54 pm |
| > "Where does this executable live on this system?" May not be perfect,
> but it's generally good enough for what I want.
Is there any way in which it is superior to the shell builtins you
probably have?
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Colin Watson 2004-06-14, 5:54 pm |
| On Mon, Jun 14, 2004 at 02:29:39PM -0400, Clint Adams wrote:
> Colin Watson wrote:
>
> Is there any way in which it is superior to the shell builtins you
> probably have?
My finger macros remember it :-)
--
Colin Watson [cjwatson@flatline.org.uk]
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Clint Adams 2004-06-14, 5:54 pm |
| > My finger macros remember it :-)
alias which='command -v' ?
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|
|
|
|
|