Re: [PATCH 7/8] odb: read alternates via sources

From: Justin Tobler <jltobler@gmail.com>
Date: Dec 9, 2025, 17:49 UTC
Message-ID: <gmhqd5nkhpk5wqjnfrn6blnxo2owvfgomfbi652fi462nf3tny@eyhy6glagywx>
In-Reply-To: <20251208-b4-pks-odb-alternates-via-source-v1-7-e7ebb8b18c03@pks.im>

On 25/12/08 09:04AM, Patrick Steinhardt wrote:

> Adapt how we read alternates so that the interface is structured around
> the object database source we're reading from. This will eventually
> allow us to abstract away this behaviour with pluggable object databases
> so that every format can have its own mechanism for listing alternates.

Ok so IIUC, the idea here is that eventually we want each source to be able to define it's own way to parse its alternates. This is needed because with pluggable ODBs a given ODB source maynot even use the filesystem and thus any alternates it may define would need to be parsed in a different manner. I suppose some future ODB source types may not even want to support child alternates.

Question: the interface of odb_source_read_alternates() still expects
parsed alternates to be written to the output strvec. The sources don't
get added to the ODB source list until odb_add_source() is invoked on
the source. Does this mean odb_add_source() will have to be able to
handle various different types of ODB sources? If so, will these be
differentiated by some sort of URI?

The patch itself here looks good.

-Justin