Received: from vps892.directvps.nl (ikke.info [178.21.113.177])
	by nld3-dev1.alpinelinux.org (Postfix) with ESMTPS id 42E387819E6
	for <~alpine/devel@lists.alpinelinux.org>; Mon, 30 Dec 2019 17:54:47 +0000 (UTC)
Received: by vps892.directvps.nl (Postfix, from userid 1008)
	id 14EB54400C6; Mon, 30 Dec 2019 18:54:46 +0100 (CET)
Date: Mon, 30 Dec 2019 18:54:46 +0100
From: Kevin Daudt <kdaudt@alpinelinux.org>
To: Rasmus Thomsen <oss@cogitri.dev>
Cc: Timo Teras <timo.teras@iki.fi>, ~alpine/devel@lists.alpinelinux.org
Subject: Re: new package format and repository layout changes
Message-ID: <20191230175446.GD846450@alpha>
References: <20191230145542.1a7ca9cf@vostro>
 <11500e3dc7d7da1a3d6acf4e1d855906630f6c31.camel@cogitri.dev>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <11500e3dc7d7da1a3d6acf4e1d855906630f6c31.camel@cogitri.dev>

On Mon, Dec 30, 2019 at 02:12:25PM +0000, Rasmus Thomsen wrote:
> Hello,
> 
> > 4. version handling
> > 
> > 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.
> > 
> > Alternative would be introduce some sort of concept similar to
> > debian/pacman package "epoch".
> > 
> > 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
> 

Wouldn't build-time timestamps interfere with reproducable builds? A
better option would be to use commit timestamps, so that it's at least
stable.