On Sun, Jun 16, 2002 at 10:00:31PM -0500, Manoj Srivastava wrote:
Branden A list of criteria other than just run for F in $(grep-available -F
Branden Essential -s Package yes | awk '{print $2}'); do dpkg -L $F | egrep
Branden '^/s?bin/.'; done, that is.
Sounds like a fine criteria
On Mon, Jun 17, 2002 at 01:07:23PM +1000, Herbert Xu wrote:
Branden Robinson [EMAIL PROTECTED] wrote:
Further, /bin/bash is available and provides both type and test as
builtins.
Bad news for any Debian port that wants to use ash as its Essential
shell, then.
I hate to break it to
On Sun, Jun 16, 2002 at 07:31:32PM +0200, Jochen Voss wrote:
On Sun, Jun 16, 2002 at 11:53:50PM +1000, Anthony Towns wrote:
On Sun, Jun 16, 2002 at 01:48:21AM -0500, Branden Robinson wrote:
Documentation good. Ad hockery bad.
That's your opinion, not mine, and not the word of God that you
On Sun, Jun 16, 2002 at 03:13:23PM -0500, Branden Robinson wrote:
Aj, on the other hand, is logically asking for continuing to
use package priority
I thought he was asking that we use package essentiality, though I
suppose one could argue that essential is a virtual priority, one
Branden == Branden Robinson [EMAIL PROTECTED] writes:
Branden On Sun, Jun 16, 2002 at 10:00:31PM -0500, Manoj Srivastava wrote:
A list of criteria other than just run for F in $(grep-available -F
Essential -s Package yes | awk '{print $2}'); do dpkg -L $F | egrep
'^/s?bin/.'; done, that
Branden Robinson [EMAIL PROTECTED] wrote:
I hate to break it to you but all the shells that could potentially
serve as /bin/sh in Debian provide type and test as builtins. That
includes ash.
And which(1)?
I do not see why we should use which. As I have stated previously, we
already
On Mon, 17 Jun 2002, Manoj Srivastava [EMAIL PROTECTED] wrote:
Does this meet your size criteria for fitting in /? Would it
be acceptable for embedded systems?
^
I may be just stupid, but what does /usrness[1] have to do with embedded
systems? After
[ben]
[snipped a bunch of irrelevant crap in order to focus on the obviously
ridiculous]
[Anthony]
Documentation can often be a nuisance: if there's too much of it or
if it's badly written so it's hard to find anything, or if it doesn't
match reality, or if the burden of maintaining the
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Manoj Srivastava wrote:
Actually, adding to the utility set could be an issue,
especially for low memory (ipaq/Zaurus, anyone?) or embedded
systems.
Since embedded systems are most likely going to use dpkg or something
dpkg-like in strange ways (not installing all files), theres
On 16-Jun-02, 15:30 (CDT), Chris Waters [EMAIL PROTECTED] wrote:
On Sun, Jun 16, 2002 at 02:17:12PM -0500, Steve Greenland wrote:
It's not superfluous: if it's up to the developer, then they can move a
binary from one to the other with no warning or discussion.
Not if that binary has
On 16-Jun-02, 22:04 (CDT), Manoj Srivastava [EMAIL PROTECTED] wrote:
Having an explicit, separate documentation of technical things
that has to be maintained, or else it slips out of synchronization
with reality, is certainly not to be preferred to haveing a
deterministic way of
On Mon, Jun 17, 2002 at 10:45:09AM -0500, Steve Greenland wrote:
Because it's not reliable. At least some portion of it is subject to the
random whims of the package maintainers (or, far more likely, the random
whims of bug reporters and a package maintainer who is (understandably)
unaware
On Mon, Jun 17, 2002 at 10:32:03AM -0500, Steve Greenland wrote:
On 16-Jun-02, 15:30 (CDT), Chris Waters [EMAIL PROTECTED] wrote:
On Sun, Jun 16, 2002 at 02:17:12PM -0500, Steve Greenland wrote:
It's not superfluous: if it's up to the developer, then they can move a
binary from one to
14 matches
Mail list logo
