On Sun, 2008-10-12 at 18:08 +0000, Kevin Kofler wrote:
> Braden McDaniel <braden <at> endoframe.com> writes:
> >
> > On Sun, 2008-10-12 at 10:30 +0200, Nicolas Mailhot wrote:
> > > So if Oracle was freely redistributable tomorrow an rpm that just put
> > > the pre-generated Oracle files in the right place would be ok with you?
> >
> > Getting to this question from what I said requires so many logical leaps
> > that it's not worth entertaining.
>
> For you, all the questions you cannot answer are "not worth entertaining". :-/

That's a baseless assertion. If you're really interested in my answer,
mail me off-list. I'm not going to do it here because the question is
an obvious attempt at baiting with the goal of making this thread less
useful for coming to any sort of conclusion.

> > Are you claiming that by creating tarballs that are designed to be used
> > without having the autotools installed, the GNU build system is
> > impairing free software?
>
> I'll let Nicolas answer that (as he's the one you asked), but generated files
> definitely make it harder to exert your freedom to modify the software
> (especially if you need the exact same versions of the autotools or you run
> into trouble, which is what spawned your guideline and thus this discussion in
> the first place) and I don't see what advantages they bring.
>
> > "Ground" level is the upstream source provided by the developer.
>
> But here what upstream includes is _not_ source, it's a generated file!

That distinction requires knowledge of the toolchain; it is deliberately
designed to be irrelevant to tarball users (of which rpmbuild is one).
And aside from exceptional situations, it is.

Guidelines aren't generally about exceptional situations. They're about
articulating best practice for common situations. Exceptional
situations frequently warrant... exceptions.

> If you define everything in the upstream tarball as "source", then Oracle's
> binaries are "source" too, which is absurd.

What Oracle provides in their tarball is the source for an RPM generated
from that tarball. That's a statement of fact, regardless of the form
the source takes or how it must (or must not) be transformed in the
process of creating the RPM.

You are welcome to find a more specific term for what you mean. "Source"
has a more general meaning than the one you're trying to apply.

> > Applying necessary patches to the build scripts in order to build
> > binaries does not make anything less free.
>
> Sure, but forbidding us to patch the actual source code on the ground that
> it "invites breakage" does.

Maybe you should reread the subject of this thread. I haven't advocated
"forbidding" anything.

> > If a packager wants to include changes to the build script sources in
> > the source RPM, I have absolutely no objection to that. But applying
> > those changes as part of the build wins nothing and invites breakage.
>
> Why should we jump through hoops to patch generated files and regularly update
> the patches because they'll invariably break if we can just run autoreconf? It
> is our (the individual package maintainers') problem to fix things if an
> autotools update breaks them anyway!

Because it affects more than just you. We won't have libtool2 in Fedora
10 because people do what you're advocating. That means there are
upstream developers who will be waiting that much longer for it and not
taking care of problems upstream on their own.

--
Braden McDaniel e-mail: <braden@endoframe.com>
<http://endoframe.com> Jabber: <braden@jabber.org>


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Braden McDaniel <braden <at> endoframe.com> writes:
> You are welcome to find a more specific term for what you mean. "Source"
> has a more general meaning than the one you're trying to apply.

I'm using the definition in the GPL:
> The “source code� for a work means the preferred form of the work for making
> modifications to it.

Obviously autogenerated files are not "source code" under that definition. You
are the one using the wrong term.

Kevin Kofler

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Braden McDaniel wrote:
> On Sun, 2008-10-12 at 18:08 +0000, Kevin Kofler wrote:

>>> If a packager wants to include changes to the build script sources in
>>> the source RPM, I have absolutely no objection to that. But applying
>>> those changes as part of the build wins nothing and invites breakage.
>> Why should we jump through hoops to patch generated files and regularly update
>> the patches because they'll invariably break if we can just run autoreconf? It
>> is our (the individual package maintainers') problem to fix things if an
>> autotools update breaks them anyway!
>
> Because it affects more than just you. We won't have libtool2 in Fedora
> 10 because people do what you're advocating. That means there are
> upstream developers who will be waiting that much longer for it and not
> taking care of problems upstream on their own.
>
Uhm... no. We won't have libtool-2.2 in Fedora 10 because it's a big
change and it's past beta.

If Fedora is to be relevant to developers as well as users we need to be
conscious of the fact that even developer tools shouldn't change in a
major, backwards incompatible way at the end of a release.

-Toshio

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Sun, 2008-10-12 at 19:10 -0700, Toshio Kuratomi wrote:
> Braden McDaniel wrote:
> > On Sun, 2008-10-12 at 18:08 +0000, Kevin Kofler wrote:
>
> >>> If a packager wants to include changes to the build script sources in
> >>> the source RPM, I have absolutely no objection to that. But applying
> >>> those changes as part of the build wins nothing and invites breakage.
> >> Why should we jump through hoops to patch generated files and regularly update
> >> the patches because they'll invariably break if we can just run autoreconf? It
> >> is our (the individual package maintainers') problem to fix things if an
> >> autotools update breaks them anyway!
> >
> > Because it affects more than just you. We won't have libtool2 in Fedora
> > 10 because people do what you're advocating. That means there are
> > upstream developers who will be waiting that much longer for it and not
> > taking care of problems upstream on their own.
> >
> Uhm... no. We won't have libtool-2.2 in Fedora 10 because it's a big
> change and it's past beta.

Well, yeah, *now*. libtool 2.2 is not particularly new. This one's
been hanging out there for some time.

Had this been the low-collateral-damage sort of upgrade that it ought to
have been, it seems pretty likely that it would have gone in. That, at
least, is what the comments in bug 435737 lead me to believe.

> If Fedora is to be relevant to developers as well as users we need to be
> conscious of the fact that even developer tools shouldn't change in a
> major, backwards incompatible way at the end of a release.

I'm not suggesting otherwise.

--
Braden McDaniel e-mail: <braden@endoframe.com>
<http://endoframe.com> Jabber: <braden@jabber.org>


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Mon, 2008-10-13 at 01:37 +0000, Kevin Kofler wrote:
> Braden McDaniel <braden <at> endoframe.com> writes:
> > You are welcome to find a more specific term for what you mean. "Source"
> > has a more general meaning than the one you're trying to apply.
>
> I'm using the definition in the GPL:
> > The “source code� for a work means the preferred form of the work for making
> > modifications to it.
>
> Obviously autogenerated files are not "source code" under that definition. You
> are the one using the wrong term.

The term in question is "source", not "source code".

(And furthermore, the GPL, as is common for a legal document, defines
several key terms that do not have a consistent, generally accepted
meaning. The definitions have authority only within the scope of the
document. Seeing such a definition is a pretty good indication that
either the term does not have a broadly accepted definition or the
document is relying some particular subtlety of that meaning.)

--
Braden McDaniel e-mail: <braden@endoframe.com>
<http://endoframe.com> Jabber: <braden@jabber.org>


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Sun, 2008-10-12 at 17:59 +0000, Kevin Kofler wrote:

[snip]

> What you're missing is that Fedora _already_ has guidelines requiring to build
> everything from source (which are enforced for Java and Mono stuff, for
> example),

What you mean is that there are guidelines applicable to Java and Mono,
right? If you're really saying that there's a guideline that applies
more generally, link please.

> it's just that the autotools files are still considered "source",

That's right. They *are* considered that. So, again, if you want to
change that, you should propose an appropriate guideline.

> which they really aren't.

Maybe. But they aren't delivered with the binary RPM; so how this
matters (or is the least bit similar to the Java/Mono situation) is not
clear.

Do you also want to use doxygen to regenerate API documentation included
in a tarball, despite the fact that a different doxygen version's subtle
stylesheet and markup changes could totally mangle the docs? How are you
going to catch *that* breakage?

--
Braden McDaniel e-mail: <braden@endoframe.com>
<http://endoframe.com> Jabber: <braden@jabber.org>


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Braden McDaniel <braden <at> endoframe.com> writes:
> Do you also want to use doxygen to regenerate API documentation

Yes, definitely! In fact, the KDE packages already do this. And have to do it,
because KDE does not include Doxygen output in their tarballs (and rightfully
so).

> included in a tarball

You're incorrectly assuming it is shipped in the tarball in the first place.

> despite the fact that a different doxygen version's subtle
> stylesheet and markup changes could totally mangle the docs?

I've yet to see that happen. Maybe Doxygen simply cares more about backwards
compatibility than the autotools.

Kevin Kofler

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Sat, 2008-10-11 at 14:07 -0400, Braden McDaniel wrote:
> When the estimate of "300 broken packages" was tossed out in the libtool
> 2.2.x thread, I figured there was no way *that* many packages could be
> running autoreconf or libtoolize. But I have been surprised to find no
> advice against this practice in Fedora's packaging guidelines; and in
> light of that, the number is not quite so incredible.
>
> While forbidding the use of autoreconf (or similar: autoconf, automake,
> libtoolize, etc.) in specfiles is probably too extreme, I do think it's
> appropriate for the packaging guidelines to point out the pitfalls of
> this practice and advise packagers to avoid it where possible.
>
> So what are those pitfalls? By running autoreconf, the RPM build becomes
> exposed to different versions of autoconf, automake, and libtool than
> were used by the upstream developer to create the upstream source
> package. Newer versions of these tools have the potential to introduce
> incompatibilities, breaking the RPM build. Rather than patching
> configure.[ac,in] and Makefile.am, a more resilient approach is to patch
> the configure script and Makefile.in files.

No thanks. Patching Makefile.am at least stands a chance of applying
correctly across multiple releases of the package. Worse, patching the
generated files stands a good chance of missing an instance of whatever
you were patching for when the next release comes out.

Packages change version much more often than libtool changes version.
I'd rather go with the method that's resilient against the more common
change.

- ajax
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Mon, 2008-10-13 at 09:35 +0000, Kevin Kofler wrote:
> Braden McDaniel <braden <at> endoframe.com> writes:
> > Do you also want to use doxygen to regenerate API documentation
>
> Yes, definitely! In fact, the KDE packages already do this. And have to do it,
> because KDE does not include Doxygen output in their tarballs (and rightfully
> so).
>
> > included in a tarball
>
> You're incorrectly assuming it is shipped in the tarball in the first place.

No, I'm not. I'm talking specifically about cases where it is.

> > despite the fact that a different doxygen version's subtle
> > stylesheet and markup changes could totally mangle the docs?
>
> I've yet to see that happen. Maybe Doxygen simply cares more about backwards
> compatibility than the autotools.

Then you haven't been looking very hard. Or you're just looking at
packages which use nearly all of the doxygen default settings. Because
this sort of breakage happens quite frequently with doxygen.

--
Braden McDaniel e-mail: <braden@endoframe.com>
<http://endoframe.com> Jabber: <braden@jabber.org>


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Mon, 2008-10-13 at 09:16 -0400, Adam Jackson wrote:
> On Sat, 2008-10-11 at 14:07 -0400, Braden McDaniel wrote:
> > When the estimate of "300 broken packages" was tossed out in the libtool
> > 2.2.x thread, I figured there was no way *that* many packages could be
> > running autoreconf or libtoolize. But I have been surprised to find no
> > advice against this practice in Fedora's packaging guidelines; and in
> > light of that, the number is not quite so incredible.
> >
> > While forbidding the use of autoreconf (or similar: autoconf, automake,
> > libtoolize, etc.) in specfiles is probably too extreme, I do think it's
> > appropriate for the packaging guidelines to point out the pitfalls of
> > this practice and advise packagers to avoid it where possible.
> >
> > So what are those pitfalls? By running autoreconf, the RPM build becomes
> > exposed to different versions of autoconf, automake, and libtool than
> > were used by the upstream developer to create the upstream source
> > package. Newer versions of these tools have the potential to introduce
> > incompatibilities, breaking the RPM build. Rather than patching
> > configure.[ac,in] and Makefile.am, a more resilient approach is to patch
> > the configure script and Makefile.in files.
>
> No thanks. Patching Makefile.am at least stands a chance of applying
> correctly across multiple releases of the package.

Patching Makefile.in stands a reasonable chance of that, too. Exactly
what the odds are depends greatly on the nature of the change; and it is
certainly the case that for a class of changes, the patch to Makefile.am
is more likely to apply cleanly. Your implication that a patch to
Makefile.in stands no chance of applying cleanly to future releases is
simply hyperbole.

> Worse, patching the
> generated files stands a good chance of missing an instance of whatever
> you were patching for when the next release comes out.

I think the claim of such a "good chance" is, once again, hyperbole.
Sure, there's *some* chance. And there's *some* chance of that
regardless of what you file patch. Again, just what sort of increase to
the likelihood of failure we're talking about depends greatly on the
nature of the change.

> Packages change version much more often than libtool changes version.
> I'd rather go with the method that's resilient against the more common
> change.

If you ran autoreconf, you also need to worry about upgrades to autoconf
and automake in addition to libtool. Still, there are certainly
packages that have more frequent releases than all three of those put
together. So from the point of view of an individual maintainer, I see
where you're coming from. But I have a problem with the practice of
regenerating these files when the broad application of this practice
winds up presenting a serious impediment to upgrading one of these build
tools in Fedora. That didn't have to happen.

But if all you did was run "automake", I'm pretty sure upgrading libtool
won't break your package. In fact, I'm not even sure that running
"autoreconf" (without arguments) is sufficient to incur breakage. What
is nearly guaranteed to cause breakage is running "autoreconf -f". And
not only is it likely to cause breakage, it's going to be completely
unnecessary in all but *very* unusual cases.

I can accept that my objectives for resiliency may not be shared by all
packagers. I think it's possible to craft a guideline that steers
packagers toward less deleterious invocations of the autotools (when
they feel the need to do so at all). But before trying to make any
further progress on this, I want to have a look at the packages that a
libtool2 upgrade stands to break.

--
Braden McDaniel e-mail: <braden@endoframe.com>
<http://endoframe.com> Jabber: <braden@jabber.org>


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list