Bill Mitchell writes (Re: binary-alpha and binary-sparc directories):
This seems shakey -- especially if we posit that the i386 maintainer
is in the U.S., the Mac maintainer in Germany, and the PowerPC maintainer
in Korea. Also, the upstream source maintainer might be in Romania,
and might
ncurses3.0-1.9.8a-3 should be in base, seeing as how it contains the
shared libraries.
Also, strictly speaking, ncurses-bin-1.9.8a-3 probably doesn't _need_
to be in base (I'd hope the programs in it probably aren't going to
see much use).
Also, the latest versions of minicom/lrzsz seem to have
Andy Guy writes (ftp method v2):
eg, if:
Filename: development/binary/text/a2gs-1.0-4.deb
looks for a2gs-1.0-4.deb in the ls -lR listing (it will probably
find it in text/ !).
If it cannot find a Filename field it falls back on using
pkgname-ver[-rev].deb.
That's an improvement, but
Package: emacs
Version: 19.29-4
`M-x ediff-documentation' tells me that ediff.info is missing (it is)
and that it is part of the Emacs distribution (I haven't confirmed).
In any case, I think it ought to be part of emacs.deb.
b c writes:
Brian Package: efax
Brian Version: 07a
Brian Revision: 4
Brian
Brian 1) The security hole still exists because the C0 command is still
Brian present when going into answer mode on systems that will accept
Brian incoming data connections. The string C1 should be added
Could binary-i386 be added as a symbolic link until the files are actually
moved. I'd like the version of dftp I'm about to release to handle an
architecture setting.
Brian
( [EMAIL PROTECTED] )
Date: 07 Jan 96 18:07 UT
Source: cfengine
Binary: cfengine
Version: 1.2.14-3
Description:
cfengine: A tool for configuring and maintaining operating systems
Priority: Low
Changes:
* rebuilt for elf
Files:
-rw-r--r-- 1 root staff 237483 Jan 7 10:07 cfengine-1.2.14-3.tar.gz
Erick Branderhorst writes (Re: Bug#2059: dpkg and depend on versions):
Yes, I'm sure, the transcription was in chronological order. I didn't
understand
the `5' either.
Chronological order ?
I was thinking that perhaps the was causing it?
Is the conflicting version number calculated from
Package: diald
Version: 0.10-2
The following situation seems to plague many Debian users who want to
use diald.
Christian Lynbech wrote:
I have it working now. I [...] changed the
device from /dev/cua1 to /dev/ttyS1 and diald finally started to work.
I think there must be something about the
'Ian Jackson wrote:'
I think I'll have to support `Replaces' or something, so that old
packages can have all their files `taken away' and disappear
eventually.
Here's the scenario that I hope a Replaces fiels might resolve. I'm
working on the S-lang library. Both most and Midnight Commander
Raul Miller writes (Re: binary-alpha and binary-sparc directories):
How about the option of a better record of what has happened?
For example, currently, if multiple packages supply the same file only
the most recently installed package has the files listed in it's .list
file. If we have
Erick Branderhorst writes (Re: Bug#2060: dpkg and depends on version again):
How about
= = for less/greater than or equal to
Ok
for strictly less/greater thani
Ok
for less/greater than or equal to (backwards compatibility,
generates warning from dpkg-deb)
Ok but an
Package: xserver-svga
Version: 3.1.2
Revision: 2
(and, I'd guess, other xserver packages as well)
The package won't install on a 0.93r6 system without a previous
X11 installation. It presumes the existence of nonexistent
things, and fails in postinst when they're not found.
Script started on
b c writes:
Brian (4) The /var/spool/fax is of the dialout group. Should this be
Brian the fax group instead? Also, how about setting the permission of
Brian this directory and those under it to drwxr-s--- so only people in
Brian that group can send/view faxes. The 's' would also
14 matches
Mail list logo
