Date: Thu, 2 Jan 2020 22:22:07 +0200
From: Timo Teras <timo.teras@iki.fi>
To: Kevin Daudt <kdaudt@alpinelinux.org>
Cc: Rasmus Thomsen <oss@cogitri.dev>, ~alpine/devel@lists.alpinelinux.org
Subject: Re: new package format and repository layout changes
Message-ID: <20200102222207.6808c028@vostro.lan>
In-Reply-To: <20191230180430.GE846450@alpha>
References: <20191230145542.1a7ca9cf@vostro>
	<11500e3dc7d7da1a3d6acf4e1d855906630f6c31.camel@cogitri.dev>
	<20191230175446.GD846450@alpha>
	<34cd93c2ddfb985c29b3b74862c9e71945a34954.camel@cogitri.dev>
	<20191230180430.GE846450@alpha>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Mon, 30 Dec 2019 19:04:30 +0100
Kevin Daudt <kdaudt@alpinelinux.org> wrote:

> On Mon, Dec 30, 2019 at 05:59:17PM +0000, Rasmus Thomsen wrote:
> > On Mon, 2019-12-30 at 18:54 +0100, Kevin Daudt wrote:  
> > > 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.
> > > 
> > > 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.  
> > 
> > Hm, the contents of the package would still be reproduciable, so I'm
> > not sure if that'd be actually be much of a problem, but using the
> > commit timestamps sounds good too - hadn't thought about that! :)
> 
> Reproducable builds is about the entire package, not just about the
> contents. abuild was already adjusted to account for this, although
> some changes had to be reverted due to issues.

That would probably then mean that we don't include build time in the
meta data either. Or use $SOURCE_DATE_EPOCH.

This probably implies that we need care on doing the signatures too.
E.g. ECDSA often has by defaulta random element in the signature
(there's a deterministic mode now too, but not always the default).

Timo