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. -- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers -- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
