> So if we start from the assumption that we will have a separate, totally
> unmodified source .tar.gz, that means we will have at a minimum two files.
>
> So, what can we have that other file to be?
>
> I would propose that it be a script (humanly readable, though it doesn't
> have to be the p
> I'll go further and say that I think that any approach that does not
> include as one of its goals the ability to work with totally virgin source
> archives is a total waste of time because it doesn't buy us enough to
> justify the work.
Now hold on a second there! What about packages put tog
>
> I propose that Debian source packages be constructed this way:
>
> The source package "hello.dsr" is a compressed tar archive containing
> four files.
I like this, but perhaps there should be two DELTA files, or one DELTA
file with the patch program taking arguments... remember s
I propose that Debian source packages be constructed this way:
The source package "hello.dsr" is a compressed tar archive containing
four files.
The first file is a copy of the Debian package header, for
identification purposes. It's not interpreted by the
Michael Alan Dorman <[EMAIL PROTECTED]> said:
> I'll go further and say that I think that any approach that does not
> include as one of its goals the ability to work with totally virgin source
> archives is a total waste of time because it doesn't buy us enough to
> justify the work.
> Package: elf-libc
> Version: 5.2.7-1
>
> Package: elf-gcc
> Version: 2.7.0-2
>
> Consider the following program:
> -- demo.c --
> #include
>
> int main(void) {
> if (3 > SHRT_MAX) {
> exit(1);
> }
> }
> -- end --
>
> when this program is compiled for a.out (gcc-2.6.3-4, libc-4.6.27-5)
>
On Tue, 31 Oct 1995, David Engel wrote:
>First, I prefer to go with unmodified, upstream source. Second, I
>really mean unmodified, i.e.. the Debianizing script (or whatever) must
>take care of unpacking into subdirectories, if necessary.
I'll go further and say that I think that any approach t
> 2. Secondly, we arrange that all the new base packages have code in
> the preinst that checks for the existence of the ELF libraries
> (perhaps by running /usr/bin/elf-available or something). If the
> libraries aren't found then the preinst returns a non-zero exit status
> and the upgrade abort
> > 2. It would also be good to have the same thing as above, but to
> > produce the upstream source.
> > 2a. That upstream source should be unmodified.
>
> A 'unmodified upstream source + unpack/patch thingy' would not conflict
> with 1(alt).
>
> > 3. All of the ways of unpacking our source pack
Package: kbd
Version: 0.90-3
This is not an actual bug, but in my opinion, it's not wise to have
default8x16 as the default font in /etc/rc.boot/console. Shouldn't it
rather be iso01.f16 in unix world?
The following problem reports are very old but have not yet been marked
as `taken up' by a message to [EMAIL PROTECTED] or as forwarded
to a developer by CCing a message to [EMAIL PROTECTED]
Please help ensure that these bugs are dealt with quickly, even if you
are not the package maintainer in que
> Before we get bogged down into the details of exactly what script
> should do what, &c, we need to consider what our requirements are, and
> make some overall design decisions. I think we have several
> conflicting requirements.
>
> 1. It is important to have a single file that can be downloade
[EMAIL PROTECTED] reads debian-devel . He's made noises about working
together before.
Bruce
Ian Jackson <[EMAIL PROTECTED]>> said (quoting out of order):
> [...] we need to consider what our requirements are, and
> make some overall design decisions. I think we have several
> conflicting requirements.
> 2a. That upstream source should be unmodified.
> 3. All of the ways of unpacking o
Date: Sun, 29 Oct 95 01:04 GMT
From: Ian Jackson <[EMAIL PROTECTED]>
If this is true then we need to copy the whole of the binary area from
0.93 to 1.0, so that 1.0 instantly becomes the `bleeding-edge'
distribution.
Are we going to start with an a.out 1.0 and migrate to an ELF 1.0
Package: sysvinit
Version: 2.57b-1
Until all of the bugs related to /etc/init.d scripts calling
/etc/init.d/functions are fixed, /etc/init.d/functions shouldn't
do anything (i.e., it should be an empty script). This will end
the problem with the arguments getting changed.
In addition, /etc/init.
Before we get bogged down into the details of exactly what script
should do what, &c, we need to consider what our requirements are, and
make some overall design decisions. I think we have several
conflicting requirements.
1. It is important to have a single file that can be downloaded and
then u
Bill wrote:
> Also, I think RedHat does something like this in their package admin
> tools. That's been discussed a bit in debian-devel, but I don't think
> anyone has taken the time to look at it.
I've browsed through it (http://www.redhat.com/rpm.html), and it is
remarkably like the current deb
Ian J. writes:
> I think that as the dpkg maintainer I probably have a reasonably good
> idea of how we can go about this so as to maintain minimum problems:
>
> 1. Firstly, we make sure that all our a.out packages have a Depends
> line that refers to the a.out libc in some way. We're still behin
Package: ppp
Version: 2.2
Revision: 1
It appears like when I start ppp to my ISP, that the PID placed in
/var/lock/LCK..ttyS20 (on my system) is not the same as the PID in
/var/run/ppp0.pid.
The result of this is that if another program, like UUCP, would like to
use this port, it appears like th
20 matches
Mail list logo
