Adam Williamson writes:
> [...]
>> > There's a big difference between having the upstream, who knows their
>> > configure script inside and out,
>>
>> That's a very bold assertion. ;-) Many upstream developers just copy&paste
>> their configure.ac scripts together [...]
>
> Yeah, autotools stu
Sam Varshavchik writes:
> Well, I just don't have that impression. What I do find a bit hard to
> believe is that somebody else other than the package's developer group would
> be in a better position to decide the merits of adopting a policy of
> automatically rebuilding the code using whatev
On Fri, 2011-07-15 at 18:43 +0200, Kevin Kofler wrote:
> Sam Varshavchik wrote:
> > There's a big difference between having the upstream, who knows their
> > configure script inside and out,
>
> That's a very bold assertion. ;-) Many upstream developers just copy&paste
> their configure.ac script
Kevin Kofler writes:
Sam Varshavchik wrote:
> There's a big difference between having the upstream, who knows their
> configure script inside and out,
That's a very bold assertion. ;-)
I do not see anything particularly bold about it. This seems to me like a
reasonable statement.
On 07/15/2011 11:43 AM, Kevin Kofler wrote:
> Sam Varshavchik wrote:
>> There's a big difference between having the upstream, who knows their
>> configure script inside and out,
>
> That's a very bold assertion. ;-) Many upstream developers just copy&paste
> their configure.ac scripts together fr
Richard W.M. Jones wrote:
> Has to be said that cmake just replaces one set of stupid with another
> set of stupid. The world is still waiting for a build system that is
> widely available and doesn't suck.
What's "stupid" about CMake?
Kevin Kofler
--
devel mailing list
devel@lists.fed
Sam Varshavchik wrote:
> There's a big difference between having the upstream, who knows their
> configure script inside and out,
That's a very bold assertion. ;-) Many upstream developers just copy&paste
their configure.ac scripts together from examples or other projects without
understanding t
On 07/03/2011 11:36 PM, Sam Varshavchik wrote:
> Kevin Kofler writes:
>
>> And in addition, I consider the concept of including generated files in
>> what's supposed to be a source tarball to be broken by design. A source
>> tarball is supposed to contain SOURCE code, not generated code. Anything
>
Adam Williamson writes:
On Mon, 2011-07-04 at 15:12 -0400, Sam Varshavchik wrote:
> But, personally, I don't mind the extra work, see. I just have this odd
idea
> of assigning a somewhat higher priority to having a reproducible build
> script, that produces the same results each and every ti
On Mon, 2011-07-04 at 15:12 -0400, Sam Varshavchik wrote:
> But, personally, I don't mind the extra work, see. I just have this odd idea
> of assigning a somewhat higher priority to having a reproducible build
> script, that produces the same results each and every time. I guess I've
> just
Adam Williamson writes:
On Sun, 2011-07-03 at 12:48 -0400, Sam Varshavchik wrote:
> To add to that: I never recall a single instance where I couldn't fix any
> breakage in someone else's canned configure/makefile scripts without having
> to rerun autoconf and automake.
>
> If there was a proble
On Sun, 2011-07-03 at 12:48 -0400, Sam Varshavchik wrote:
> To add to that: I never recall a single instance where I couldn't fix any
> breakage in someone else's canned configure/makefile scripts without having
> to rerun autoconf and automake.
>
> If there was a problem in the configure scr
On 07/04/2011 03:48 PM, Sam Varshavchik wrote:
> Ralf Corsepius writes:
>
>> > I've got C++ code that's more than ten years old. Still builds just
>> > fine, without any diagnostics.
>> Then you're lucky - May-be your C++ code is recent enough?
>
> No. I have the source tree right here. Large chunk
On Mon, Jul 04, 2011 at 03:07:14PM +0200, Kevin Kofler wrote:
> Nils Philippsen wrote:
> > I'd really love to be able to re-run current auto-tools on old
> > Makefile.am/configure.{in,ac} files and the results to work in all
> > cases, but right now that seems utopian to me.
>
> Yet the competitio
On Mon, 2011-07-04 at 06:25 +0200, Ralf Corsepius wrote:
> On 07/04/2011 04:37 AM, Toshio Kuratomi wrote:
> > On Mon, Jul 04, 2011 at 06:31:18AM +0530, Ankur Sinha wrote:
> >> Hi folks,
> >>
> >> Thanks all for the input. I didn't realize the subject was *this*
> >> controversial. I did find the ot
On Mon, 2011-07-04 at 15:07 +0200, Kevin Kofler wrote:
> Nils Philippsen wrote:
> > I'd really love to be able to re-run current auto-tools on old
> > Makefile.am/configure.{in,ac} files and the results to work in all
> > cases, but right now that seems utopian to me.
>
> Yet the competition ( htt
Ralf Corsepius writes:
> I've got C++ code that's more than ten years old. Still builds just
> fine, without any diagnostics.
Then you're lucky - May-be your C++ code is recent enough?
No. I have the source tree right here. Large chunks of it are quite old.
So far, most pre-ISO-C++ code I h
On 07/04/2011 02:04 PM, Sam Varshavchik wrote:
> Ralf Corsepius writes:
>
>> On 07/04/2011 01:18 PM, Sam Varshavchik wrote:
>>
>> > Both gcc and binutils are extensively regression-tested. Stuff that was
>> > compiled years ago, still works.
>> To some extend, yes,
>>
>> Nevertheless we all are per
Richard W.M. Jones wrote:
> I suspect Kevin's concern is that someone stuffs some hidden shell
> code into ./configure which isn't in configure.ac. (Of the "send all
> your private ssh keys to remote host" variety).
>
> This concern has some legitimacy. But OTOH someone could stuff the
> same co
Nils Philippsen wrote:
> I'd really love to be able to re-run current auto-tools on old
> Makefile.am/configure.{in,ac} files and the results to work in all
> cases, but right now that seems utopian to me.
Yet the competition ( http://www.cmake.org/ ) manages that very thing just
fine…
The whole
Ralf Corsepius writes:
On 07/04/2011 01:18 PM, Sam Varshavchik wrote:
> Both gcc and binutils are extensively regression-tested. Stuff that was
> compiled years ago, still works.
To some extend, yes,
Nevertheless we all are permanently fixing gcc/binutils-compatibilities,
aren't we?
Right. B
On 07/04/2011 01:18 PM, Sam Varshavchik wrote:
> Both gcc and binutils are extensively regression-tested. Stuff that was
> compiled years ago, still works.
To some extend, yes,
Nevertheless we all are permanently fixing gcc/binutils-compatibilities,
aren't we?
> The same cannot be said of autot
Kevin Kofler writes:
Sam Varshavchik wrote:
> Well, to me it makes much more sense to simply eliminate the uncertainty
> from the process. If I take the tarball that I'm going to build today, if
> I have to rebuild it next year, of a few years from -- the tarball will
> remain the same. It's not
really
useful. Best regards
Messaggio originale
Da: Richard W.M. Jones
Inviato: 04/07/2011, 12:39
A: Development discussions related to Fedora
Cc: ankursi...@fedoraproject.org
Oggetto: Re: Calling autoconf in a spec.
On Sun, Jul 03, 2011 at 11:45:09AM -0400, Tom Lane wrote:
> FWIW
On 07/04/2011 12:39 PM, Richard W.M. Jones wrote:
> On Sun, Jul 03, 2011 at 11:45:09AM -0400, Tom Lane wrote:
>> FWIW, I used to run autoconf during the builds of both the postgresql
>> and mysql packages for many years. That eventually became unnecessary
>> in both cases, but I don't recall that
On Sun, Jul 03, 2011 at 11:09:06PM -0400, Tom Lane wrote:
> Kevin Kofler writes:
> > FWIW, I think we should actually run autoreconf -i -f in ALL specfiles as a
> > matter of policy, even if we aren't changing anything,
>
> To what end? If you need to change configure.ac, that's one thing ...
>
On Sun, Jul 03, 2011 at 11:45:09AM -0400, Tom Lane wrote:
> FWIW, I used to run autoconf during the builds of both the postgresql
> and mysql packages for many years. That eventually became unnecessary
> in both cases, but I don't recall that autoconf changes ever caused me
> any trouble. (gcc, o
On Sun, 2011-07-03 at 13:31 -0400, Tom Lane wrote:
> Sam Varshavchik writes:
> > To add to that: I never recall a single instance where I couldn't fix any
> > breakage in someone else's canned configure/makefile scripts without having
> >
> > to rerun autoconf and automake.
>
> > If there wa
Tom Lane wrote:
> I grow weary of debating this with somebody who can't recognize that his
> particular situation is not universal. Many people build code for
> themselves, for instance because their preferred platform isn't shipping
> the particular version of a package they want (or not shipping
Sam Varshavchik wrote:
> Well, to me it makes much more sense to simply eliminate the uncertainty
> from the process. If I take the tarball that I'm going to build today, if
> I have to rebuild it next year, of a few years from -- the tarball will
> remain the same. It's not going to change. Simila
On 07/04/2011 04:37 AM, Toshio Kuratomi wrote:
> On Mon, Jul 04, 2011 at 06:31:18AM +0530, Ankur Sinha wrote:
>> Hi folks,
>>
>> Thanks all for the input. I didn't realize the subject was *this*
>> controversial. I did find the other discussion thread[1] which was aimed
>> at completing the draft I
Kevin Kofler writes:
And in addition, I consider the concept of including generated files in
what's supposed to be a source tarball to be broken by design. A source
tarball is supposed to contain SOURCE code, not generated code. Anything
needing to be generated should be generated during the bui
Kevin Kofler writes:
Sam Varshavchik wrote:
>
> Can you translate that. It's nonsense because many upstreams do that?
Oops, I forgot the most important word. :-(
Nonsense. Even many upstreams DON'T do that.
Only very few upstreams use a specific version of autoconf and/or automake,
most upst
Kevin Kofler writes:
> Tom Lane wrote:
>> That sounds more like dogmatism than practical thinking. It's common to
>> pre-generate some of the files in a distribution tarball, just so that
>> users aren't required to have specific tools in order to build the code
>> (unless they want to modify the
Kevin Kofler writes:
> FWIW, I think we should actually run autoreconf -i -f in ALL specfiles as a
> matter of policy, even if we aren't changing anything,
To what end? If you need to change configure.ac, that's one thing ...
but if you don't, you're just uselessly exposing yourself to risks.
Tom Lane wrote:
> That sounds more like dogmatism than practical thinking. It's common to
> pre-generate some of the files in a distribution tarball, just so that
> users aren't required to have specific tools in order to build the code
> (unless they want to modify the input files for those tools
Kevin Kofler writes:
> And in addition, I consider the concept of including generated files in
> what's supposed to be a source tarball to be broken by design. A source
> tarball is supposed to contain SOURCE code, not generated code. Anything
> needing to be generated should be generated durin
On 07/03/2011 10:31 PM, Kevin Kofler wrote:
> Sam Varshavchik wrote:
>> Ok, then when you patch configure.in, configure.ac, and/or Makefile.am, be
>> sure to also specify:
>>
>> BuildRequires: autoconf=[version]
>>
>> and
>>
>> BuildRequires: automake=[version]
>>
>> in order to have a reproducible
On Mon, Jul 04, 2011 at 06:31:18AM +0530, Ankur Sinha wrote:
> Hi folks,
>
> Thanks all for the input. I didn't realize the subject was *this*
> controversial. I did find the other discussion thread[1] which was aimed
> at completing the draft I had linked to, and as you'll notice it was
> inconcl
Sam Varshavchik wrote:
> Indeed. How dare do those upstreams publish files containing non-preferred
> form for modifications, in their tarballs?
The GPL doesn't ban shipping generated files as long as they're accompanied
by their source code. It does ban editing only the generated files without a
Sam Varshavchik wrote:
> Kevin Kofler writes:
>
>> Sam Varshavchik wrote:
>> > Ok, then when you patch configure.in, configure.ac, and/or Makefile.am,
>> > be sure to also specify:
>> >
>> > BuildRequires: autoconf=[version]
>> >
>> > and
>> >
>> > BuildRequires: automake=[version]
>> >
>> > in o
Hi folks,
Thanks all for the input. I didn't realize the subject was *this*
controversial. I did find the other discussion thread[1] which was aimed
at completing the draft I had linked to, and as you'll notice it was
inconclusive. I was hoping something had changed (the thread dates back
to 2008)
Kevin Kofler writes:
drago01 wrote:
> Exactly patching generated code is just wrong period.
+1. It's also a violation of the GPL (for GPLed projects), because you
aren't changing the preferred form for modification.
Indeed. How dare do those upstreams publish files containing non-preferred
Kevin Kofler writes:
Sam Varshavchik wrote:
> Ok, then when you patch configure.in, configure.ac, and/or Makefile.am, be
> sure to also specify:
>
> BuildRequires: autoconf=[version]
>
> and
>
> BuildRequires: automake=[version]
>
> in order to have a reproducible build.
Nonsense. Even many ups
Thanks. But the GNU build system don't require or need this by definition,
Regards
Messaggio originale
Da: Kevin Kofler
Inviato: 03/07/2011, 22:34
A: devel@lists.fedoraproject.org
Oggetto: Re: R: Re: Calling autoconf in a spec.
pinto.e...@gmail.com wrote:
> First of all Sorry
On 07/03/2011 10:34 PM, Kevin Kofler wrote:
> FWIW, I think we should actually run autoreconf -i -f in ALL specfiles as a
> matter of policy, even if we aren't changing anything, the same way we
> require Java JARs to be rebuilt from source.
please no!
curently most of the fedora packages can be
pinto.e...@gmail.com wrote:
> First of all Sorry for not quoting. It is just for telling an opinion from
> someone that know the autofu well, almost. For me this idea of patching
> generated autofu is wrong. if i have to patching the GNU build system
> there is a reason of course. Which reason is
Sam Varshavchik wrote:
> Ok, then when you patch configure.in, configure.ac, and/or Makefile.am, be
> sure to also specify:
>
> BuildRequires: autoconf=[version]
>
> and
>
> BuildRequires: automake=[version]
>
> in order to have a reproducible build.
Nonsense. Even many upstreams do that. (I k
drago01 wrote:
> Exactly patching generated code is just wrong period.
+1. It's also a violation of the GPL (for GPLed projects), because you
aren't changing the preferred form for modification.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraprojec
Ankur Sinha wrote:
> I need help with a package[0] that needs autoconf to be called before
> the build can begin. I've read this draft which addresses the issue[1].
> I used the second solution which says:
> [1] http://fedoraproject.org/wiki/PackagingDrafts/AutoConf
That draft is a draft for a re
: 03/07/2011, 19:38
A: Development discussions related to Fedora
Oggetto: Re: Calling autoconf in a spec.
On Sun, Jul 3, 2011 at 7:31 PM, Tom Lane wrote:
> Sam Varshavchik writes:
>> To add to that: I never recall a single instance where I couldn't fix any
>> breakage
drago01 writes:
On Sun, Jul 3, 2011 at 7:31 PM, Tom Lane wrote:
> Sam Varshavchik writes:
>> To add to that: I never recall a single instance where I couldn't fix any
>> breakage in someone else's canned configure/makefile scripts without
having
>> to rerun autoconf and automake.
>
>> If th
On Sun, Jul 3, 2011 at 7:31 PM, Tom Lane wrote:
> Sam Varshavchik writes:
>> To add to that: I never recall a single instance where I couldn't fix any
>> breakage in someone else's canned configure/makefile scripts without having
>> to rerun autoconf and automake.
>
>> If there was a problem in t
Sam Varshavchik writes:
> To add to that: I never recall a single instance where I couldn't fix any
> breakage in someone else's canned configure/makefile scripts without having
> to rerun autoconf and automake.
> If there was a problem in the configure script, rather than patching
> config
Tom Lane writes:
Ankur Sinha writes:
> I need help with a package[0] that needs autoconf to be called before
> the build can begin. I've read this draft which addresses the issue[1].
> I used the second solution which says:
> "When manual modification of configure or Makefile.in for the purpos
Ankur Sinha writes:
> I need help with a package[0] that needs autoconf to be called before
> the build can begin. I've read this draft which addresses the issue[1].
> I used the second solution which says:
> "When manual modification of configure or Makefile.in for the purpose of
> generating a
Hello,
I need help with a package[0] that needs autoconf to be called before
the build can begin. I've read this draft which addresses the issue[1].
I used the second solution which says:
"When manual modification of configure or Makefile.in for the purpose of
generating a patch is impractical, p
57 matches
Mail list logo
