On Fri, Aug 12, 2005 at 10:23:54PM -0400, Joey Hess wrote:
Steve Langasek wrote:
Hmm, I'm not really sure whether that fits with policy's intent regarding
the effects of the debian/clean target.
This must undo any effects that the `build' and `binary' targets
may have
Justin Pryzby [EMAIL PROTECTED] wrote:
On Fri, Aug 12, 2005 at 10:23:54PM -0400, Joey Hess wrote:
Steve Langasek wrote:
Hmm, I'm not really sure whether that fits with policy's intent regarding
the effects of the debian/clean target.
This must undo any effects that the `build'
On Sat, 13 Aug 2005, Armin Berres wrote:
You have two good choices, and one bad choice for packaging upstream
source which uses automake and autoconf and contains generated files:
1. Tolerate the big diff size, and run the autotools stuff before you
create the debian source package. This is
On Fri, 12 Aug 2005, Goswin von Brederlow wrote:
On the other hand, if you run them during build then you MUST 'unrun'
them in the clean target. Otherwise every build will get a (potentialy
hugely) different diff.gz file.
No. Just rm -f all autogenerated crap in debian/rules's clean target as
Steve Langasek wrote:
On Fri, Aug 12, 2005 at 10:15:41AM +0200, Bas Wijnen wrote:
If you rerun autoconf/automake/libtool at package build-time, when you don't
need to, what you get are large diffs against upstream every time a new
version of the autotools becomes available. Aside from wasting
On Sat, Aug 13, 2005 at 01:13:11PM +0200, Armin Berres wrote:
Steve Langasek wrote:
On Fri, Aug 12, 2005 at 10:15:41AM +0200, Bas Wijnen wrote:
If you rerun autoconf/automake/libtool at package build-time, when you don't
need to, what you get are large diffs against upstream every time a
Hello mentors,
I have some packages which use autotools. I thought it would be good to
compile as much as possible, so it is clear all the sources are correct. That
means including autoconf, of course.
However, linda doesn't agree with that:
W: gfpoken; Package Build-Depends on automake* or
also sprach Bas Wijnen [EMAIL PROTECTED] [2005.08.12.1015 +0200]:
My question is: is linda correct and should I not run autoconf from
rules.make?
*I* think linda is correct. But others disagree.
FYI: http://lists.debian.org/debian-devel/2005/03/msg00425.html
If I were you, I'd repack the
I have some packages which use autotools. I thought it would be good to
compile as much as possible, so it is clear all the sources are correct. That
means including autoconf, of course.
However, linda doesn't agree with that:
W: gfpoken; Package Build-Depends on automake* or autoconf.
This
On Fri, Aug 12, 2005 at 10:21:05AM +0200, martin f krafft wrote:
*I* think linda is correct. But others disagree.
I used to have the same opinion as Martin, but changed my mind.
It depends on the package. E.g. I have a package, that is not
maintained upstream anymore, but still very useful.
On Fri, Aug 12, 2005 at 10:55:44AM +0200, Andreas Fester wrote:
I agree with Martin that autoconf and automake should not be run from
rules, and that upstream should provide a configure script.
./configure; make; make install is what I expect to do as a user of
a (original upstream) package,
On Fri, 2005-08-12 at 10:55 +0200, Andreas Fester wrote:
configure *is* the platform independant configure script,
so why ever should I need to create it on my specific platform?
Perhaps because somebody found out that the Autotools are buggy in the
time frame between configure was built and
On Fri, Aug 12, 2005 at 10:15:41AM +0200, Bas Wijnen wrote:
I have some packages which use autotools. I thought it would be good to
compile as much as possible, so it is clear all the sources are correct. That
means including autoconf, of course.
However, linda doesn't agree with that:
W:
On Fri, Aug 12, 2005 at 02:12:57AM -0700, Steve Langasek wrote:
On Fri, Aug 12, 2005 at 10:15:41AM +0200, Bas Wijnen wrote:
I have some packages which use autotools. I thought it would be good to
compile as much as possible, so it is clear all the sources are correct.
That
means
On Fri, Aug 12, 2005 at 12:04:31PM +0200, Bas Wijnen wrote:
On Fri, Aug 12, 2005 at 02:12:57AM -0700, Steve Langasek wrote:
On Fri, Aug 12, 2005 at 10:15:41AM +0200, Bas Wijnen wrote:
I have some packages which use autotools. I thought it would be good to
compile as much as possible, so
Am Freitag, den 12.08.2005, 02:12 -0700 schrieb Steve Langasek:
On Fri, Aug 12, 2005 at 10:15:41AM +0200, Bas Wijnen wrote:
I have some packages which use autotools. I thought it would be good to
compile as much as possible, so it is clear all the sources are correct.
That
means
On Fri, Aug 12, 2005 at 01:50:33PM +0200, Daniel Leidert wrote:
Aside from wasting (a little)
space in the archive, that makes it harder for NMUers or passing developers
to see what's going on in your package.
In this case, you could use dpatch to change things and then it is not
harder
Am Freitag, den 12.08.2005, 06:12 -0700 schrieb Steve Langasek:
On Fri, Aug 12, 2005 at 01:50:33PM +0200, Daniel Leidert wrote:
Aside from wasting (a little)
space in the archive, that makes it harder for NMUers or passing
developers
to see what's going on in your package.
In
On Fri, 12 Aug 2005, Steve Langasek wrote:
On Fri, Aug 12, 2005 at 01:50:33PM +0200, Daniel Leidert wrote:
Aside from wasting (a little)
space in the archive, that makes it harder for NMUers or passing
developers
to see what's going on in your package.
In this case, you could use
W. Borgert [EMAIL PROTECTED] writes:
On Fri, Aug 12, 2005 at 10:55:44AM +0200, Andreas Fester wrote:
I agree with Martin that autoconf and automake should not be run from
rules, and that upstream should provide a configure script.
./configure; make; make install is what I expect to do as a
On Fri, Aug 12, 2005 at 10:59:23AM -0300, Henrique de Moraes Holschuh wrote:
On Fri, 12 Aug 2005, Steve Langasek wrote:
On Fri, Aug 12, 2005 at 01:50:33PM +0200, Daniel Leidert wrote:
Aside from wasting (a little)
space in the archive, that makes it harder for NMUers or passing
Steve Langasek wrote:
If you rerun autoconf/automake/libtool at package build-time, when you don't
need to, what you get are large diffs against upstream every time a new
version of the autotools becomes available. Aside from wasting (a little)
space in the archive, that makes it harder for
Steve Langasek wrote:
Hmm, I'm not really sure whether that fits with policy's intent regarding
the effects of the debian/clean target.
This must undo any effects that the `build' and `binary' targets
may have had, except that it should leave alone any output files
23 matches
Mail list logo
