On Sat, 19 Mar 2005, Henning Makholm wrote:
> Better have them restricted to developers and users who modify code
> than to have them happen randomly to people who just want to build the
> unmodified package.
Like, say, our security and QA teams. I would very much like their opinion
on this, they
Scripsit Junichi Uekawa <[EMAIL PROTECTED]>
>> > To a certain degree, those would have been fixed if people
>> > build-depended on auto*, as they would have picked up fixed versions
>> > of the .m4 files.
>> But that has to be offset against the huge number of bugs that would
>> occur if we ran a
Hi,
> > To a certain degree, those would have been fixed if people
> > build-depended on auto*, as they would have picked up fixed versions
> > of the .m4 files.
>
> But that has to be offset against the huge number of bugs that would
> occur if we ran auto* at run time and had everything break e
Hi,
> >The current practice and trend is going the other way,
> >but I strongly recommend for using autoconf/automake in build scripts.
> Does cdbs do it right?
I've looked at the source of cdbs, and I figure that users of
cdbs can configure and set variables:
DEB_AUTO_UPDATE_LIBTOOL
DEB_AUTO
Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes:
> This only works because dpkg-buildpackage calls the clean target before
> doing anything, BTW. And all things Debian follow its lead (i.e. pbuilder,
> the buildds, sbuild, cvs-buildpackage, etc all either use dpkg-buildpackage
> or do thin
Hi,
> >The current practice and trend is going the other way,
> >but I strongly recommend for using autoconf/automake in build scripts.
>
> Does cdbs do it right?
I've actually not looked into how cdbs handles things,
so I cannot comment on it.
regards,
junichi
--
To UNSUBSCRIBE,
Scripsit Tollef Fog Heen <[EMAIL PROTECTED]>
> * Henning Makholm
> | When I provide a configure script in the source package it means, on
> | the contrary, that I *have* tried it and therefore has some kind of
> | evidence that it will probably work for other people too.
> You have probably only
* Henning Makholm
| When I provide a configure script in the source package it means, on
| the contrary, that I *have* tried it and therefore has some kind of
| evidence that it will probably work for other people too.
You have probably only tried it on one architecture.
A lot of the bugs I see
On Mon, Mar 14, 2005 at 01:18:12AM -0500, Kurt B. Kaiser wrote:
> Machine generated files (e.g. configure) constructed by autotools
> should not be in CVS.
> However, these files (as generated by the Debian maintainer's autotools
> run before the upload) should be included in the source package vi
Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes:
>> When I include the configure script in my source packages, I can feel
>> pretty confident that they package I upload will stay buildable even
>> if a week from now autoconf or automake gets updated to something not
>> backwards compatible.
On Mon, 14 Mar 2005 09:04:17 +0900, Junichi Uekawa
<[EMAIL PROTECTED]> wrote:
>The current practice and trend is going the other way,
>but I strongly recommend for using autoconf/automake in build scripts.
Does cdbs do it right?
Greetings
Marc
--
-- !! No co
On Mon, 14 Mar 2005, Kurt B. Kaiser wrote:
> Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes:
> >> When I include the configure script in my source packages, I can feel
> >> pretty confident that they package I upload will stay buildable even
> >> if a week from now autoconf or automake gets
Hi,
> However, if I left it to the source package to run autoconf by itself
> weach time it is build, it could slide into unbuildability _without me
> or anybody else noticing_ before it is too late and we have
> not-buildable-anymore code sitting around in the archive, and most
> likely even in
On Thu, 2005-03-10 at 12:05 -0600, Adam Heath wrote:
> On Fri, 11 Mar 2005, Paul Hampson wrote:
>
> > * timestamp skew means that the autobuilt makefiles will try
> > to rebuild configure from configure.in even if configure is patched by
> > dpkg-source at the same time as configure.in
> >
Scripsit Kurt Roeckx <[EMAIL PROTECTED]>
> Or are you saying that all build dependencies should be removed,
> since they all can cause you problems.
I am saying that this particular build dependency can be removed
without causing problems that have anywhere near the severity of the
problems that
Hi Kurt,
On Sun, Mar 13, 2005 at 03:40:23PM +0100, Kurt Roeckx wrote:
> > That's the point, actually: If I build-depend on autoconf, I *cannot*
> > know that it will actually build after the next update to autoconf,
> > because most likely nobody will try it.
>
> If it's known that a new major v
On Sun, Mar 13, 2005 at 02:02:29PM +, Henning Makholm wrote:
> Scripsit Kurt Roeckx
>
> > And how can you know you can actually build it if you
> > never tried it?
>
> That's the point, actually: If I build-depend on autoconf, I *cannot*
> know that it will actually build after the next updat
Scripsit Kurt Roeckx
> And how can you know you can actually build it if you
> never tried it?
That's the point, actually: If I build-depend on autoconf, I *cannot*
know that it will actually build after the next update to autoconf,
because most likely nobody will try it.
When I provide a config
On Sun, Mar 13, 2005 at 12:04:59PM +, Henning Makholm wrote:
> Scripsit Daniel Schepler <[EMAIL PROTECTED]>
>
> > - Putting autoconf-generated files in the source package is nearly as
> > fragile as generating them at build time. If there are changes in
> > autoconf which break the configure.
On Sun, 13 Mar 2005, Henning Makholm wrote:
> Scripsit Daniel Schepler <[EMAIL PROTECTED]>
> > - Putting autoconf-generated files in the source package is nearly as
> > fragile as generating them at build time. If there are changes in
> > autoconf which break the configure.ac etc, then the next ti
Scripsit Daniel Schepler <[EMAIL PROTECTED]>
> - Putting autoconf-generated files in the source package is nearly as
> fragile as generating them at build time. If there are changes in
> autoconf which break the configure.ac etc, then the next time you want
> to make other changes or bring your c
[EMAIL PROTECTED] (Paul Hampson) writes:
> The arguments _for_ build-depending on the various autotools are (off
> the top of my head)
Here are some other reasons pro that I can think of:
- Putting autoconf-generated files in the source package is nearly as
fragile as generating them at build ti
[EMAIL PROTECTED] (Paul Hampson) writes:
> The arguments _for_ build-depending on the various autotools are (off
> the top of my head)
>
> (In the below, read autoconf as autoconf/automake. ^_^)
>
> * keeps .diff.gz small and readable, as configure changes are
> not included. And small configure
On Fri, 11 Mar 2005, Paul Hampson wrote:
> * timestamp skew means that the autobuilt makefiles will try
> to rebuild configure from configure.in even if configure is patched by
> dpkg-source at the same time as configure.in
> * A solution for this is in the above-mentioned README.Debian
New
On Thu, Mar 10, 2005 at 01:52:45PM +0100, martin f krafft wrote:
> I have often tried to argue my position on automake/autoconf in
> packages' build dependencies: I do not think they belong there. If
> a package does not build without automake or autoconf, it is broken
> and should be fixed. Howeve
Scripsit martin f krafft <[EMAIL PROTECTED]>
> I seem to recall the devel-reference or some similar document to
> specifically address this issue, but I cannot find the location
> anymore.
Are you thinking about /usr/share/doc/autotools-dev/README.Debian.gz?
--
Henning Makholm "They discussed
I have often tried to argue my position on automake/autoconf in
packages' build dependencies: I do not think they belong there. If
a package does not build without automake or autoconf, it is broken
and should be fixed. However, bugs like #298336 seem to suggest that
other maintainers deem it entir
27 matches
Mail list logo
