On Sat, Jul 29, 2006 at 07:28:13PM -0400, Jeff Johnson wrote:
> The only I objective meaning I'm aware of for %{dist} is that the
> package was built with a certain value of %{dist} defined.
>
> This is an entirely advisory mechanism, and there is no test possible
> other than examining the build system to find that, indeed, %{dist} is
> set to some desired value.
No, the package does not examine its environment to guess the valua of
the disttag, it is given (as in the example at the beginning at this
thread) upon invocation of rpmbuild.
> There are means other than editing every bleeping *.spec file in the
> world to add %{dist} to achieve exactly the same output packages,
> with exactly the same string in the Release: field. Manually editing
> every spec file is poor engineering,
Indeed, that's why it's automated in my local environment.
> and one specfile everywhere is the wrong goal.
Well, everybody his goals, please, and mine is to share a specfile for
the two lines of distros I support. Others feel the same about
specfile maintenance, that's why at the end disttags are takeing over
the world.
> So the point of dist tags is to insure that if the rest of EVR in a
> package is identical, the trailing part of the release determines
> "newer" because %{dist} has a simple monotonically integer at the
> very end?
>
> That's an absolutely draconian method to force "newer" by demanding
> that every other part of EVR is identical so that %{dist} is the
> sole determinant of "newer".
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.
> 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?
--
Axel.Thimm at ATrpms.net
Attachment:
pgphGjuoC2TM3.pgp
Description: PGP signature
_______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
