Disttag for Fedora 7 and beyond

[Michael Schwendt]

On Fri, 5 Jan 2007 20:32:45 +0100, Axel Thimm wrote:

> On Fri, Jan 05, 2007 at 08:05:24PM +0100, Michael Schwendt wrote:
> > On Fri, 5 Jan 2007 19:09:00 +0100, Axel Thimm wrote:
> > > > > and the next update needed at least 23:3.0.  E.g. the epoch
> > > > > inflation everywhere make it mandatory to start checking all your
> > > > > versioned BRs and
> > > > 
> > > > Versioned BRs are not affected, since the RPM Epoch never specifies an
> > > > API version.
> > > 
> > > What makes you say this? How about epoch of the perl package itself?
> > 
> > It is specific to the RPM package, not defined by Perl at all.
> > 
> > > They very much define the ABI/API in this case by themselves.
> > 
> > There is no Epoch in Perl's versioning scheme. Not in the old one,
> > and not in the new one either.
> 
> Ehem, perl itself is currently at epoch 4.

Perl itself isn't, the RPM package in FC6 is "perl <= 4:5.8.8".

> Any package that needs to
> define that it needs a specific range of perl ABI/API to work
> with/build against needs to know the version-epoch mapping history of
> perl or to reply on artificially virtual provides.

You build against a single target. In FC6 it's Perl v5.8.8.  Its API/ABI
is defined by its version and in detail by a lot of stuff in the
"Provides". The Epoch of the RPM package has nothing to do with that.
 
> > Why do you want to add Epochs to versioned Perl dependencies?
> 
> I don't, but if there are such I have to. Say for example that xmltv
> depends on perl(Lingua::Preferred) >= 0.2.4.  If perl-Lingua-Preferred
> had an epoch the above check would need to get this epoch added and
> properly maintained by humans or machines.

Why? You want 'perl(Lingua::Preferred) >= 0.2.4', and either your
build/target environment provides this version or not.