On Jul 29, 2006, at 6:58 PM, Axel Thimm wrote:
On Sat, Jul 29, 2006 at 05:11:56PM -0400, Jeff Johnson wrote:
Seriously Jeff, it works, and the alternative of having web-counters
just isn't. Why haven't we package monkeys used a web-counter?
Are we
that stupid? Obviously you think so.
"Works" how? You have never defined the goal of adding %{dist} and
so its impossible to tell what the goal of adding %{dist} without
asking someone what it means.
Of course it was defined. It was given previously in this thread and
it's about allowing the same set of binary packages built from the
same src.rpm on different releases of a distro to respect the desired
upgrade path. I thought that was clear, even the OP's subject is
rather self-explaining.
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.
That is a branding, not and engineering issue.
Sure adding %{dist} is cheap advertising for various political
entities.
I'm sorry, but I'll remain on the engineering floor. Not sure who
would even want to abuse that for political or branding issues, and I
don't care either. I merely look at the technical demand which is
one-specfile-for-all-releases and seek (and find) a solution within
the given constraints.
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, and one specfile everywhere is the wrong goal.
Do the majority of packages built with
%define dist fc4
"work" on a system that chooses to identify itself with
%define dist fc5
Quite likely. That's the engineering, not the branding, truth.
You probably miss the point of disttags. The is never ever a %define
disttag <something> in the specfile. This would defeat the whole
purpose. The specfile is to be kept as release/distro agnostic as
possible. The disttag is something tagged onto the package from its
external environment (where the binary package is built in) to place
it into the proper upgrade path.
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".
Other means to achieve upgradeability are possible.
And just to make sure that wasn't lost in the discussion: The disttag
is also not to be abused for identifying features of the
environment/release. The purpose is well-defined as *solely* for
ensuring proper upgrade paths.
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.
73 de Jeff
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list
