My thoughts on repotag

Michael Schwendt mschwendt.tmp0701.nospam at arcor.de
Mon Mar 19 13:36:53 UTC 2007


On Mon, 19 Mar 2007 12:27:48 +0000 (GMT), Lance Davis wrote:

> On Mon, 19 Mar 2007, Michael Schwendt wrote:
> 
> > It still fails for branch-specific (i.e. dist-specific) fixes, where the
> > least-significant portion of the full %release value is increased for
> > rebuilds or minor fixes:
> >
> > 	foo-1.0.0-2.el5.fdr.1 < foo-1.0.0-2.el5.rf
> 
> but foo-1.0.0-2.el5.fdr < foo-1.0.0-2.el5.rf so it wouldnt be installed in 
> the first place if you had those repos configured ...

And that is flawed.

The package release string gets longer without telling anything about
which of the packages is newer. Anyone still want to claim that these tags
don't influence RPM version comparison? ;) Packagers would be forced to
increment the most-significant part of %release, breaking the dist-upgrade
path,

    foo-1.0.0-3.el4.fdr > foo-1.0.0-2.el5.fdr

unless superfluous mass-updates and mass-rebuilds are used.

> It could be mandated that repotag always comes last and is preceeded by a 
> (default 0) build id
> 
> eg foo-1.0.0-2.el5.1.fdr > foo-1.0.0-2.el5.0.fdr

Looks like EL5.1 and EL5.0 to me and is something like:

  Release: 2%{?dist}.0%{?repo}

?? And then you want packagers to bump release in that macro-madness?

%dist and %repo -- and %fedora and %rhel -- are undefined by default.
Rebuild such src.rpms results in completely incompatible packages.

  foo-1.0.0-2.1 > foo-1.0.0-2.0 > foo-1.0.0-2.el5.1.fdr > ...
 




More information about the epel-devel-list mailing list