Well, i think the basic principle is
split everything that people might want to install independantly or
that can be upgraded independantly
So i think it's a good idea to enable people to install most parts of
your suite, but leave the httpd away (if they want to use some other
httpd etc.)
I
Erich Schubert [EMAIL PROTECTED] writes:
Well, i think the basic principle is split everything that people
might want to install independantly or that can be upgraded
independantly
Mmmm...I'd rather go for a basic principle of Use as few packages as
possible, but no fewer. There's no need
At 0:56 +0200 10/12/01, Gustavo Noronha Silva wrote:
Em Thu, 11 Oct 2001 23:53:00 +0200
Regnat Nikolaus [EMAIL PROTECTED] escreveu:
Unpacking cursorsmall (from cursorsmall_1-1_i386.deb) ...
dpkg: error processing cursorsmall_1-1_i386.deb (--install):
trying to overwrite
Regnat Nikolaus [EMAIL PROTECTED] writes:
I'm trying to create a package which replaces the black cursor from
XFree86 with a white one. Unfortunately it is not possible to
install a packge which overwrites files already installed by another
package. I get the following message if I try to
On Fri, Oct 12, 2001 at 01:10:47PM +0200, Falk Hueffner wrote:
Packages must not overwrite other packages' files. You can perhaps use
the alternatives mechanism. See update-alternatives(8).
Diversions (dpkg-divert) would be appropriate in this case.
Any package can divert another's files.
#include hallo.h
Hamish Moffatt wrote on Fri Oct 12, 2001 um 10:34:06PM:
On Fri, Oct 12, 2001 at 01:10:47PM +0200, Falk Hueffner wrote:
Packages must not overwrite other packages' files. You can perhaps use
the alternatives mechanism. See update-alternatives(8).
Diversions (dpkg-divert)
The upgraded independantly is a good point. As an
in-development package, I wouldn't at the point be
entirely happy with people running older versions if
they wanted stability.
You can use versioned Depends for that, if that is necessary.
If not necessary, don't do this. But during heavy
On Fri, Oct 12, 2001 at 05:19:11PM +0200, Eduard Bloch wrote:
Hamish Moffatt wrote on Fri Oct 12, 2001 um 10:34:06PM:
Diversions (dpkg-divert) would be appropriate in this case.
OTOH only one package can apply diversion on a file, this would not work
with multiple packages. This method is
On Fri, Oct 12, 2001 at 12:41:55AM +0200, Ralf Treinen wrote:
BTW, the upstream author tried to compile his program with gcc 3.01
and did not succeed. I am not enough of an expert in C programming
to solve a problem that he cannot solve. However, if anyone likes
to help me on this I will be
On Tue, Oct 09, 2001 at 09:25:05PM -0500, Lex Spoon wrote:
Hello, I've put together a couple of Debian packages, and would love to
contribute them to the Debian Project. I'm willing to maintain them.
However, I don't have an advocate or sponsor. Can anyone help me out?
For anyone who
Hello developers,
Attached you'll find the new README.Debian file of the autotools-dev
package. Any comments/suggestions/fixes? The whole GNU autotools stuff is
a hairy topic, I know... but if we don't document how to best use them (in
Debian) somewhere, it will only get worse.
Suggestions of
Henrique,
(GNU makefile snippet):
export DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
export DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
./configure --build=$(DEB_BUILD_GNU_TYPE) --host=$(DEB_HOST_GNU_TYPE) \
... (other
On Fri, 12 Oct 2001, Erich Schubert wrote:
Well, i think the basic principle is
split everything that people might want to install independantly or
that can be upgraded independantly
The upgraded independantly is a good point. As an
in-development package, I wouldn't at the point be
Well, i think the basic principle is
split everything that people might want to install independantly or
that can be upgraded independantly
So i think it's a good idea to enable people to install most parts of
your suite, but leave the httpd away (if they want to use some other
httpd etc.)
I don't
Erich Schubert [EMAIL PROTECTED] writes:
Well, i think the basic principle is split everything that people
might want to install independantly or that can be upgraded
independantly
Mmmm...I'd rather go for a basic principle of Use as few packages as
possible, but no fewer. There's no need to
At 0:56 +0200 10/12/01, Gustavo Noronha Silva wrote:
Em Thu, 11 Oct 2001 23:53:00 +0200
Regnat Nikolaus [EMAIL PROTECTED] escreveu:
Unpacking cursorsmall (from cursorsmall_1-1_i386.deb) ...
dpkg: error processing cursorsmall_1-1_i386.deb (--install):
trying to overwrite
Regnat Nikolaus [EMAIL PROTECTED] writes:
I'm trying to create a package which replaces the black cursor from
XFree86 with a white one. Unfortunately it is not possible to
install a packge which overwrites files already installed by another
package. I get the following message if I try to
On Fri, Oct 12, 2001 at 01:10:47PM +0200, Falk Hueffner wrote:
Packages must not overwrite other packages' files. You can perhaps use
the alternatives mechanism. See update-alternatives(8).
Diversions (dpkg-divert) would be appropriate in this case.
Any package can divert another's files.
Hello developers,
Attached you'll find the new README.Debian file of the autotools-dev
package. Any comments/suggestions/fixes? The whole GNU autotools stuff is
a hairy topic, I know... but if we don't document how to best use them (in
Debian) somewhere, it will only get worse.
Suggestions of
#include hallo.h
Hamish Moffatt wrote on Fri Oct 12, 2001 um 10:34:06PM:
On Fri, Oct 12, 2001 at 01:10:47PM +0200, Falk Hueffner wrote:
Packages must not overwrite other packages' files. You can perhaps use
the alternatives mechanism. See update-alternatives(8).
Diversions (dpkg-divert)
Henrique,
(GNU makefile snippet):
export DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
export DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
./configure --build=$(DEB_BUILD_GNU_TYPE) --host=$(DEB_HOST_GNU_TYPE) \
... (other
On Fri, 12 Oct 2001, Erich Schubert wrote:
Well, i think the basic principle is
split everything that people might want to install independantly or
that can be upgraded independantly
The upgraded independantly is a good point. As an
in-development package, I wouldn't at the point be
entirely
The upgraded independantly is a good point. As an
in-development package, I wouldn't at the point be
entirely happy with people running older versions if
they wanted stability.
You can use versioned Depends for that, if that is necessary.
If not necessary, don't do this. But during heavy
On Fri, Oct 12, 2001 at 05:19:11PM +0200, Eduard Bloch wrote:
Hamish Moffatt wrote on Fri Oct 12, 2001 um 10:34:06PM:
Diversions (dpkg-divert) would be appropriate in this case.
OTOH only one package can apply diversion on a file, this would not work
with multiple packages. This method is
On Fri, Oct 12, 2001 at 12:41:55AM +0200, Ralf Treinen wrote:
BTW, the upstream author tried to compile his program with gcc 3.01
and did not succeed. I am not enough of an expert in C programming
to solve a problem that he cannot solve. However, if anyone likes
to help me on this I will be
On Tue, Oct 09, 2001 at 09:25:05PM -0500, Lex Spoon wrote:
Hello, I've put together a couple of Debian packages, and would love to
contribute them to the Debian Project. I'm willing to maintain them.
However, I don't have an advocate or sponsor. Can anyone help me out?
For anyone who
26 matches
Mail list logo
