Karsten Hopp wrote:
Ralf Corsepius schrieb:
On Tue, 2008-05-06 at 11:02 -0400, Christopher Aillon wrote:
On 05/05/2008 11:43 PM, Casey Dahlin wrote:
Matthias Clasen wrote:
On Mon, 2008-05-05 at 23:28 -0400, Casey Dahlin wrote:
If you'd have read the thread, you'd have noticed I already pointed
out multiple times, if you want to keep Firefox in the distro, you
need to keep autoconf213 for the forseeable future.
Not at all. The firefox project should ship their infrastructure, such
that developers can install it into their development environments.
They do. Our Firefox rpm rebuilds just fine without autoconf213. The
autoconf213
package is required to build the necessary files when the tarballs are
created.
FYI: I've canceled my request to block the older autofoo packages as the
discussion
here showed that we just can't do that.
I'd like to see a reviewer guideline instead that new packages should be
checked
if they really need to run autofoo during the build and if they really
require to
be built with ancient autofoo.
So I have a few things against my initial impression of how this draft
could turn out (Note: draft unseen of course so you might intend
something entirely different:
1) It's micro-managing. Packagers should know whether they have to
regenerate configure/Makefile.in based on the patches that they're
applying. If we're seeing widespread use of the autotools when there's
no need to do it then it seems like a candidate to add... but is that
the case? The list of packages which presently BuildRequire the
autotools is very small so I'm not sure this is the case.
2) Having the packager and reviewer know that the package requires older
autotools to build raises the barrier to entry significantly. If you
can give us a checklist of items to look for in configure.in that limit
the package to ancient autotools then we are in business. This is
something better done upstream.
Combining these and asking people who know enough to patch
configure.in/Makefile.am to try to decide whether they can use current
autoconf/automake instead of the compat packages could be a compromise
solution but even there, you run into issues where the packager knows
enough to patch:
- GTKHTML_MAX_VER=3.9
+ GTKHTML_MAX_VER=3.10
but not enough to recognize when older autoconf is arequirement.
If we really and truly want to get upstreams off of older versions of
autoconf/automake, we need to introduce it into our toolchain and have
every package that uses autotools invoke the current autoconf/automake
in the build. This will bring errors to the surface so we can fix them
and submit the changes upstream.
Note that I think this is a horrendous idea as it completely disregards
one of the core tenets of the autotools (the system that builds the
package does not need to have the autotools installed) but if we want to
have our packagers actively hunting for incompatibilities with the new
autotools, then it seems like a necessary step.
-Toshio
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
