Todd Zullinger writes:
Ditto for the epoch hack -- my solution fixes the original underlying reason for having an epoch in the first place.Eh? So how do you handle the sometimes retarded versioning schemes of upstream sources? Or the occasional need to push an older version of something as an update?
You have to break the built-in assumption that the newer version of a package always carries a later version number. The whole reason for the epoch is the automatic assumption regarding version and release numbers.
If just replace the built-in version-release succession assumption with a resource definition. Right now, packages have a list of provided resources, and a list of required resources. This becomes just another type of a package resource -- the updated resource. 99% of the time, you're going to have:
Updates: package < version-release.archwhere version and release is this package's. But, in those few situations, you'll change the default. Your package will have a lower version, but specifies that it updates anything with a higher version number. All the rest of the existing logic stays the same.
And if the original upstream versions are what's retarded, you just version the packages properly, and don't worry about it. Just because the upstream versions are retarded, your packages don't have to be. Put the current date as the first version component, and upstream's bizarre version label after it, and your update process become sane again.
The whole problem that epoch supposed to solve is due to the built-in assumptions that packages with higher versions update packages with lower versions. If you replace that with just another resource definition that's part of the package itself, this whole mess goes away completely.
And this includes all those instances where you change the arch label of a package. That's always lots of fun, but once you replace a built-in assumption with a resource definition, this again becomes a routine process.
Attachment:
pgp3Tb4pGppTb.pgp
Description: PGP signature
