tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: handling versioning change

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 <> 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

Home | Main Index | Thread Index | Old Index