1. Epoch is not used in package's name, it's only available in metadata. End-user (binary packages' consumer) should never need to know if cowsay's package name is cowsay-20160103$suffix or cowsay-1.0$suffix, neither to determine which one is newer. 2. Speaking of : as meta character reservation is irrelevant. It can be presented as cowsay E1 1.0 vs E0 20160103. Nobody cares. The point is to have independent versioning from PKGVERSION, not visible to users as it's irrelevant to anybody else than a package's maintainer. 3. Pain of incompatibility? Lack of function "Obsoletes" (after package's rename) and PKGEPOCH is pushing pkgsrc backwards. (There are few other features, I don't want to talk about them right now here making pkgsrc suboptimal in comparison with RPM* from 2000). Please note that Red Hat tracks its binary packages' updates without such interruptions like that, with renames and reordering versions since 90ties. (I don't know what was before ~1995 when they escaped the Perl trap in order to rewrite RPM to C). SUSE has extensions but they are able to flawlessly handle upgrades of packages (of course modulo human errors) since ever. The same with Mandrake successors (currently Mageia). In the pkgsrc world we request from users and developers to perform these awkward manual interventions, that enforces me to just rebuild all packages from scratch rather than handle it manually or semiautomatically with existing utilities. * yeah, I used to know RPM internals. On 28.11.2016 01:16, Alistair Crooks wrote: > Now we'll go onto the ramifications of using ':' for the binary > packages we create, and in pkgsrc in general: > > a) we now need to to have a ':' character in some package names, and > not in others > b) how do we deal with having a ':' character when performing > pre-requisite parsing in pkgsrc makefiles? (the ':' character is > already used there, for different purposes) > c) interix support with a ':' character in the name? "Yeah, right" > > Oh, oh, oh, I know, it's just a ':' character, change it to something > else. Right, so let's use a ',' character, which is visually > indistinguishable from '.' in some typefaces with a small font size. > Oh, yes, not ',', we'll use '#', no ';', '|', no, '/', something else. > > All in all, you fairly quickly come round to the fact that calling the > package something else is the least intrusive way of dealing with > this. After all, it's what we do IRL when describing things > > A. "I got a new iphone today" > B. "6 or 7?" > A. "7. iphone7" > > Given that there should be no RTT in our own parsing of the package > name, we need to distinguish, a priori, between packages. So we have > kde2, kde3, kde4. py27, py33, etc. In doing so, the version is > embedded in the metadata, in the package name itself, and we're > instantly aware of context. And it's why any form of epoch-type > event-denotation is awkward at best, irrelevant and detrimental to > understanding at worst, and certainly doesn't help in any way. > > On 27 November 2016 at 15:35, Joerg Sonnenberger <joerg%bec.de@localhost> wrote: >> On Sun, Nov 27, 2016 at 07:07:08PM +0100, Kamil Rytarowski wrote: >>> 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. >> >> As I said before, it doesn't really provide any significant advance over >> the example I just gave. Given all the pain the incompatiblity would >> introduce, I don't really see the point. There are better use cases for >> ':' as meta character too. >> >> Joerg >>
Attachment:
signature.asc
Description: OpenPGP digital signature