Date: Mon, 30 Dec 2019 17:59:17 +0000
To: Kevin Daudt <kdaudt@alpinelinux.org>
From: Rasmus Thomsen <oss@cogitri.dev>
Cc: Timo Teras <timo.teras@iki.fi>, ~alpine/devel@lists.alpinelinux.org
Reply-To: Rasmus Thomsen <oss@cogitri.dev>
Subject: Re: new package format and repository layout changes
Message-ID: <34cd93c2ddfb985c29b3b74862c9e71945a34954.camel@cogitri.dev>
In-Reply-To: <20191230175446.GD846450@alpha>
References: <20191230145542.1a7ca9cf@vostro>
 <11500e3dc7d7da1a3d6acf4e1d855906630f6c31.camel@cogitri.dev>
 <20191230175446.GD846450@alpha>
Feedback-ID: LZW2MXNaH7NSG88i8lGpebeqB0wmcl0-3TbzkSuzsmAwEQspn4GI-WRe8j3PhRL4SBmua4rQWq6fadPcLS5uxQ==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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,
> >=20
> > > 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. :)
> >=20
> > 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.
> >=20
> > Regards,
> >=20
> > Rasmus
> >=20
>=20
> 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! :)

Regards,

Rasmus