Date: Fri, 17 Jan 2020 09:31:10 +0200
From: Timo Teras <timo.teras@iki.fi>
To: Natanael Copa <ncopa@alpinelinux.org>
Cc: ~alpine/devel@lists.alpinelinux.org
Subject: repo pinning, whether to include repository name in pkg [was Re:
 new package format and repository layout changes]
Message-ID: <20200117093110.13bfdc9f@vostro.lan>
In-Reply-To: <20200117032933.421dfe8b@vostro>
References: <20191230145542.1a7ca9cf@vostro>
	<20200116121517.0a050f85@ncopa-desktop.copa.dup.pw>
	<20200117032933.421dfe8b@vostro>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Fri, 17 Jan 2020 03:29:33 +0200
Timo Teras <timo.teras@iki.fi> wrote:

> So the problem in general is that if you have edge's main + community
> untagged, and @testing tagged.
> 
> Then the following happens:
>  1. install package from @testing
>  2. that package gets updated in our repo, and the old one get's
> removed 3. the index is updated
> 
> After this we have system with package from @testing. To be able to
> recalculate the system consistency, we need to be able to verify that
> the currently installed package came from @testing. If this is not
> possible apk would currently try to enforce upgrading to the updated
> version, even if something else was just added (the updated tagged
> package would be preferred).
> 
> This becomes even more important on run-from-ram system. When on
> reboot recalculating what can be installed. On above instance the
> package would no be installed if the tag cannot be validated.
> 
> Currently, the installed database contains the repository tag as-is
> where it was installed. This is inserted by apk on install time. For
> run-from-ram systems this is also stored in the cache repository
> index. 
> 
> But the above system is fragile. And can fail in certain scenarios
> too.
> 
> The point is that having the @tag syntax in repositories that is
> locally configurable is problematic. My idea was to perhaps keep the
> @tag syntax but bind it to something that comes from the index and is
> present in the packages.

I've been thinking this further.

The original issue why this was really, really needed was that the
run-from-ram setups can properly boot from cache when the package is no
longer in any index.

Another option to solve this, would be following scheme:
 - no repository information in the package
 - no storing of the tag info to installed-db nor cache
 - resolve repo tags always on run time
 - if package is installed, assume it has been in repository with
   proper tag. thus ignore any tag checking for these.
   (caveat: if someone modifies 'world' manually and adds the tag, that
   is not picked up properly)
 - for run-from-ram systems, the store a separate list in the overlay
   that contains the exact set of packages the system is running.

   caveat: after ugprade, one would need to do lbu commit to store the
   new system setup. though, this might in fact be preferred function,
   since this would also fix a known issue that doing "apk update" but
   not "apk upgrade" and then booting might break the reboot.

One more kludgy thing is the virtual packages. Those probably need to
be treated similarly as 'world'. Either as etc/apk/vpkg config file or
similar.

Having said all this. I am still somewhat concerned and thinking that
putting repository name to the package might be useful thing. But
perhaps in should be the originally-built-from-repository and not the
index name.

Does any of you share my concerns that the repo name should be signed?

Timo