compat (libgal2 gtkhtml3) packages for Fedora Extras

[Michael Schwendt]

On Sun, 14 Nov 2004 17:16:08 +0000, Michael A. Peters wrote:

> > The prefix 0.fdr has nothing to do with the Epoch. It ensures that any
> > package merged into Fedora Core would win version-release comparison.

> Their scheme though is rather complex - I guess to overcome shortcoming  
> in rpm's versioning - but still overly complex.

At least the package naming and versioning guidelines are documented
at all. ;)
 
> It's probably vepoch I was remembering, but not having read the docs -  

The "versioned specific epoch" (vepoch) is a different concept.
Basically, it's just an ordinary most significant number in the
%release field (which can followed by an arbitrary part to its right).
which to increment with every package revision. It's unrelated to
RPM's %epoch. And the documentation is clear on that.

Example:
Release: 5.1-0.fdr.4.2

  5.1 = software version
  0.fdr = fedora.us specific prefix
  4 = actual package release number = vepoch
  2 = Fedora Core 2

The vepoch is more than a simple release number, since it is also used
to deal with upstream versioning schemes which break RPM version
comparison (e.g. weird alpha/beta/rc/snapshot version names):

Release: 5.1-0.fdr.0.1.beta3.2

  5.1 = software version first part (!)
  0.fdr = fedora.us specific prefix
  0.1 = vepoch scheme for pre-releases, 1 = actual package revision
  beta3 = software version postfix ==> 5.1beta3 is full version
  2 = Fedora Core 2

Release: 5.1-0.fdr.0.2.beta3.2

  5.1 = software version first part
  0.fdr = fedora.us specific prefix
  0.2 = vepoch scheme for pre-releases, 2 = actual package revision
  beta3 = software version postfix ==> 5.1beta3 is full version
  2 = Fedora Core 2

Naming the package 5.1beta3-0.fdr.1 would make an upgrade to final
5.1-0.fdr.1 impossible without increasing the real %epoch, because
"5.1beta3" > "5.1". For that final release, in fedora.us scheme,
vepoch would simply turn from 0.x to x as in first example.

> well anyway, the epoch in the release tag makes sense to me because it  
> gives a visual representation of what the epoch is just by looking at  
> the file.

Duplicating %epoch in %release would only add confusing complexity.
Tools like Yum display the Epoch in package versions as
%epoch:%version-%release. This adds enough confusion already for
users who need libfoo.i386 1:1.2 and only find libfoo-1.2.

> I'm not suggesting Fedora change things, but epoch makes sense, a  
> complex release scheme, and vepoch - and there you have it.
> 
> Oh well.
> 
> So - any fedora extras people (who know the release scheme ;) want to  
> package these for extras?

Probably the same people who would step forward and also package and
maintain gnomesword2 and monodoc and "other software that needs the
older shared libraries" for Fedora Extras? :)

-- 
Fedora Core release 3 (Heidelberg) - Linux 2.6.9-1.667
loadavg: 1.18 1.29 0.85