Date: Mon, 30 Dec 2019 14:12:25 +0000
To: Timo Teras <timo.teras@iki.fi>, ~alpine/devel@lists.alpinelinux.org
From: Rasmus Thomsen <oss@cogitri.dev>
Reply-To: Rasmus Thomsen <oss@cogitri.dev>
Subject: Re: new package format and repository layout changes
Message-ID: <11500e3dc7d7da1a3d6acf4e1d855906630f6c31.camel@cogitri.dev>
In-Reply-To: <20191230145542.1a7ca9cf@vostro>
References: <20191230145542.1a7ca9cf@vostro>
Feedback-ID: LZW2MXNaH7NSG88i8lGpebeqB0wmcl0-3TbzkSuzsmAwEQspn4GI-WRe8j3PhRL4SBmua4rQWq6fadPcLS5uxQ==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hello,

> 4. version handling
>=20
> Sort of unrelated, but something I'd like to also bring up once
> again.
> Since now that if we do proper distribution / branch tracking. And
> the
> package downgrades happen at times. I'm wondering if we should make
> the
> package version "informative" only. And use the build_time to decide
> which package is the "preferred version". In most cases it is the
> latest built package from the repository we want to be using.
>=20
> Alternative would be introduce some sort of concept similar to
> debian/pacman package "epoch".
>=20
> Though another way to look at it that the buildtime is the
> automatically generated epoch number. :)

Having the buildtime as automatically generated epoch number sounds
great to me, I don't see any situation where we'd have a package with a
'fresher' buildtime that isn't meant to replace the previous version of
that package and that'd make downgrades work automagically.

Regards,

Rasmus