On Jul 29, 2006, at 8:00 PM, Axel Thimm wrote:
On Sat, Jul 29, 2006 at 07:28:13PM -0400, Jeff Johnson wrote:
No, you miss it again (are you doing this on purpose???). The evr are
the same to begin with. As said this *is* the same specfile and there
is no desire to fork it for each supported distro/release combination
creating a specfile maintenance nightmare. As it stands currently
ATrpms for instance supports 11 distro/release combinations. Dag even
more (13?). Having a dozen copis of the same specfile/src.rpm only
with a manually (or web-counter ...) edited Release tag is really poor
engineering IMO.
We're saying the same thing in different words. All of EVR is identical
except for %{dist}, so %{dist} determines newer.
Another hint: Wouldn't it be nice to build fc4 packages on a fc5
system instead of having to maintain multiple distro versioned
chroot's? The issue for a significant number of packages that, say,
need only -lc is usually accidental pollution from a glibc versioned
symbol that leads to a dependency that would not be met, mirroring
the underlying fault that there would a symbol that would not be
present on the older system. Why not address the mapping of symbols
directly, rather than adding a magic %{dist} marker which pretends
to accomplish the same goal, i.e. insuring that a package can be
installed/upgraded.
Even if it were glibc alone, every FC release, especially between FC2
and FC5 had new and improved gcc/glibc security improvements (against
execstack, buffer overflows, double frees and so on) that require a
rebuild. Before that it would be nptl/tls and in the future new
distribution properties will modify the build results. So while
compatibility is possible, why not build in chroots and have the
package fully exploit the environment?
Building in chroot's is essential for many reasons.
However, starting to explicitly identify what the failures are, and
ways to
work around them, is important too.
The majority of package rebuilds these days are mechanical trash and
burn to achieve goals
like
All packages built with newest gcc, so if anything breaks, its
gcc's fault.
or
Attempt self-hosting, all packages rebuild themselves.
This is not development (as in fixing bugs or implementing features)
but purely release engineering,
casually inflicted on end-users.
73 de Jeff
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list
