Disttag for Fedora 7 and beyond

[Michael Schwendt]

On Fri, 5 Jan 2007 19:09:00 +0100, Axel Thimm wrote:

> > > How many packagers have been bitten by Requires: foo >= 2.0.1 while
> > > they really needed foo >= 17:2.0.1 
> > 
> > Users, not packagers.
> 
> That's the same, or if one get's bitten he bites the next in the food
> chain ;)

The packagers made the packages, becauses the strict dependency works
for them. But it's not transparent for the users.
 
> > For everyone else including packagers, in the distribution there is
> > only one package "foo" [...]
> 
> Nah, that's an arghument against having versioned dependencies at all,
> which is not what we want.

It's an argument against superfluous and desolate versioned deps, yes.
 
> > > 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.

> Furthermore the automated perl dependencies that by definition lack an
> epoch, can become an indirect BR quite easily ...
> 
> Ask the people that had to cope with the epochs in perl itself, that
> required special handling in all perl dependency detection and that
> creates redundant parts of redhat-rpm-config that we cannot send back
> upstream, because any epochs are non-portable. So we get to sit on all
> the special handling stuff and this just for automatic depedencies for
> perl the package.

Why do you want to add Epochs to versioned Perl dependencies?

> > Epochs are not evil. Even the old explicit "Epoch: 0" policy solved
> > more problems [of an epoch promotion bug in rpm] than it created,
> 
> Ouch, no, let me respectfully disagree 100%. That broke apt, the only
> depsolver back in these days, and until we knew what it was it created
> an epoch inflation never seen again since. And it did solve nothing,
> because the problem was in comparing epoch "none" vs epoch "0",

c.f. http://www.wideopen.com/archives/rpm-list/2003-June/msg00137.html
There are more gems to find.

> and guess what: There were no packages with explict epoch "0" back then.

It broke comparing "no Epoch" with "Epoch!=0". Sub-packages that were
moved into a new main package with an own versioning scheme around that
time were affected, for instance.