Received: from vps892.directvps.nl (ikke.info [178.21.113.177]) by nld3-dev1.alpinelinux.org (Postfix) with ESMTPS id D0E7D781AF8 for <~alpine/devel@lists.alpinelinux.org>; Mon, 30 Dec 2019 18:04:30 +0000 (UTC) Received: by vps892.directvps.nl (Postfix, from userid 1008) id 9D9A64400C6; Mon, 30 Dec 2019 19:04:30 +0100 (CET) Date: Mon, 30 Dec 2019 19:04:30 +0100 From: Kevin Daudt To: Rasmus Thomsen Cc: Kevin Daudt , Timo Teras , ~alpine/devel@lists.alpinelinux.org Subject: Re: new package format and repository layout changes Message-ID: <20191230180430.GE846450@alpha> References: <20191230145542.1a7ca9cf@vostro> <11500e3dc7d7da1a3d6acf4e1d855906630f6c31.camel@cogitri.dev> <20191230175446.GD846450@alpha> <34cd93c2ddfb985c29b3b74862c9e71945a34954.camel@cogitri.dev> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <34cd93c2ddfb985c29b3b74862c9e71945a34954.camel@cogitri.dev> 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. > > > > > > 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. > > 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 > 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. Kevin