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? :=) 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. 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. > 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. Let's settle on stylistic differences :=) -- Axel.Thimm at ATrpms.net
Attachment:
pgpL7Z7zSAOc6.pgp
Description: PGP signature
_______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
