-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Jul 29, 2006, at 12:38 PM, Axel Thimm wrote:
On Sat, Jul 29, 2006 at 11:52:53AM -0400, Jeff Johnson wrote:
On Jul 29, 2006, at 11:36 AM, Axel Thimm wrote:
The probable reason for the request (can't guess the OP's
motivation, but it very much looks so) is to ensure proper upgrade
paths within "fc" when rebuilding the same src.rpm package on
different releases of the distro, which is a very handy method to
support/maintain several releases with one specfile, and which has
spread all over the repos by now.
Widespread usage does not insure problems are resolved.
Guaranteeing upgradeability on a per-distro basis by configuring
Release: through manually administered policies is intrinsically
doomed as well.
Well, it works well on the field for over three years now. So from a
purely non-academic POV I'd say there is no issue.
Hint: Try exposing a web-counter that is shared cooperatively between
different build systems. That is easier engineering than discussing
rpm EVR comparison schemes until hell freezes over.
Easier? :=)
Yes. There are 2 problems, specifying a rule that preserves
upgradeability is rather easy. The far harder problem is deploying
and enforcing the rule. A web-counter, with appropriate local cache
for the web-deprived, is a far far simpler deployment than teaching
every package monkey in the world about %{dist} again again again.
Disttags are accepted entities in everyday's packaging, there isn't
much discussion around them anymore. And a web-counter or any shared
resource to manage this differently is far more error prone.
All sorts of crapola in rpm packages is "accepted". I can point to
numerous
package flaws, like the insanity of having
%clean
[ X"%{buildroot}" != "X/" ] && rm -rf %{buildroot}
and all its silly variants for just one of many "accepted" practices.
Accepted != maintainable
Accdepted != correct
Accepted != simple
and the list goes on and on.
Don't forget that the packages are immediately recognized as being
based on the same src.rpm, and why should there be an inflation on
buildtags? Personally I think as long as the sources remain the same
(which includes the specfile), no Release tag bump should happen. And
the disttag idiom does just that.
Which is why RPMTAG_SOURCEPKGID was added years ago.
But clearly using RPMTAG_SOURCEPKGID instead hasn't found its way onto
what you consider "accepted" practice yet.
Wouldn't be hard at all to add options to express, say,
I want a Release that is newer than latest in repo1 but older
than
next chosen for repo1.
where the web-counter thingy maintains Release: state persistently.
Yes, but why, when there is already an existing, extremely cheap, well
working mechanism in place.
I won't touch "well working".
And "cheap" has several other meanings than "simply accomplished"
that perhaps
you did not intend.
Let's settle on stylistic differences :=)
Let's not. The weird crapola that you package monkey's are adding to
Release: is
leading to a bleary meaningless fog of obscurity for many users that
is going to force rpm
to abandon its existing EVR comparison for something else instead.
But, by all means, feel free to put whatever you want onto the
Release: fire hydrant.
73 de Jeff
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFEy5bduHNkGyA5spERAmaUAJ9Cgur1LapTZZFr3fBuEX/fBuA8AgCg58UM
yAVOP4peLKrJKVPJme/8dWE=
=/Ndq
-----END PGP SIGNATURE-----
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list
