Disttag for Fedora 7 and beyond

[Michael Schwendt]

On Sat, 6 Jan 2007 10:31:40 +0100, Axel Thimm wrote:

> > > > > 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".
> 
> Exactly, and we're talking about package dependencies and how the ugly
> epoch is needed for expressing the desired API/ABI in BuildRequires.

You don't need to. The Epoch is irrelevant in Perl's API/ABI definition.
"perl <= 4:5.8.8" means that any version, any Epoch is provided. You could
do "Requires: perl = 2:5.005" and "Requires: perl = 1:4", it would be
satisfied, too.

Btw, defining Perl's ABI via a single integer would be very close to an
impossible mission.

> > > 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.
> 
> You are promoting to tailor specfiles against target
> releases.

Non-versioned dependencies in spec files are more portable than
versioned ones.

Generally, I promote build requirement checks in configure scripts. There
are too many ">=" requirements in spec files, which are out-of-date,
superfluous, or plain wrong. At run-time, only exact dependencies help.
Any ">=" is dangerous when no other safety checks are active.

On the other hand, if you refer to mass-updates, where an updated spec
file is copied over to multiple target releases and alters history
(e.g. in %changelogs), yes, I would be better if that were not done.

> This is a wrong thing to do for many things, for one I want
> to keep the same specfile across different releases (*and*
> distributions like Fedora <-> RHEL specfile sharing). Removing all
> versioning in specfiles because "we know" fcN has foo version XYZ
> leads to broken and low-quality specfiles.

Hmm, that are your personal preferences which conflict with what can
happen due to Epochs in RPM version comparison. Personally, I don't like
to rely on the relationship of different products. The life-time of a
package in one distribution could have lead to a different EVR than with
another distribution. At least where using Epoch instead of a versioning
scheme for pre-releases is not forbidden. Further, a "Dist Epoch"
preferably would not be visible in spec files. It would only help in
answering the question which of two packages is for a newer distribution.
Upgrade path sanity.

> > > > 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.
> 
> And it may even provide it with a lower version and a higher epoch, so
> my version requirements go banana.
>
> Epoch bad.

No.

A Perl module definition does not have any RPM Epoch in its versioning.
Never. You require an Epoch-less Perl module "Provides".

A lower module version would provide 'perl(Lingua::Preferred) = 0.2.0',
for example, which would break your dependency even if the RPM had an
increased Epoch. 0.2.0 < 0.2.4

The Epoch is irrelevant here. So, let's escape from this bad example,
please.


Assuming you meant a package dependency in general, not a dependency on a
Perl module, adding an Epoch to your versioned requirement does not help
either. Any increase in Epoch would break the dependency. If you only
wanted to demonstrate that, no need to go in circles and drag in Perl
stuff. It is ">=" which is bad already.

Any increase in Version could make it break, too, since you don't
guarantee that 'perl(Lingua::Preferred) = 0.3.0' is compatible, and
neither 'perl-Lingua-Preferred = 0.4.0'.

Going back to a lower version plus setting Epoch is the bad thing. Sure.
But there is no alternative solution (other than a silent and questionable
rollback) for downgrades during development.

Still, it is possible to omit Epochs from automated dependency checks,
provided that any versioned requirements in binary rpms are accurate
enough.