On 27.11.2016 18:21, Alistair Crooks wrote: > There's always 4) > > Pick a new PKGBASE name - lz4github, or lz4zip, to represent the > change-of-versioning-scheme > > and 5) > > ignore it, just change the version number, and rely on the exact new > version for a period (3 months?) during which time people will do the > upgrade almost by default > > > > > > On 27 November 2016 at 06:31, Joerg Sonnenberger <joerg%bec.de@localhost> wrote: >> On Sat, Nov 26, 2016 at 10:45:57AM -0500, Greg Troxel wrote: >>> 1) just change the version and people will have to deal, once >> >> Just make sure to add some appropiate limits to avoid the old version >> where necessary. >> >>> 2) do something like 132.1.7.3 and be kludgy forever >> >> More like go with 999a1.7.3 or so. That's reasonable dense and still >> orders well. >> >>> 3) Implement some silent metadata in versions just for tools that >>> check versons, so that the human-presented version is right. I dimly >>> recall discussion of this (EPOCH?) but can't find it. >> >> All epoch syntaxes are more or less as bad as the above, some just stick >> the marker to the end. >> >> Joerg >> I don't like to request from users to manually handle package renaming or removing in order to install smaller & newer version. It should work out of the box. PKGEPOCH mechanism would solve it now and add a proper tool in future, adding incremental version prepending PKGVERSION, PKGEPOCH 1 would form a version like 1:1.0.3, that will be always higher than any version with the default PKGEPOCH 0. http://rpm.org/max-rpm-snapshot/s1-rpm-depend-manual-dependencies.html
Attachment:
signature.asc
Description: OpenPGP digital signature