[gentoo-dev] developing a separate repo spec

[gentoo-dev] developing a separate repo spec

[Tim Harder]

Hi all,

Is there any interest these days in developing and maintaining a
separate repo spec [1]? Among other uses, it would help in describing
standardized repo features related to metadata/layout.conf settings
allowing devs to reference a single, canonical source in order to
support repo/profiles features.

The current spec doesn't define many repo specific features leading to
people jamming all sorts of conditional features in metadata/layout.conf
via profile-formats and other entries, none of which is defined in the
current spec.

Mostly I'm asking because I'm tired of trying to support a pseudo-spec
and am quite close to dropping pkgcore's support for the few
profile-formats features it tries to enable. 

Thanks,
Tim

[1]: https://bugs.gentoo.org/417013

Re: [gentoo-dev] developing a separate repo spec

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 940 bytes --]

>>>>> On Mon, 29 Mar 2021, Tim Harder wrote:

> Is there any interest these days in developing and maintaining a
> separate repo spec [1]? Among other uses, it would help in describing
> standardized repo features related to metadata/layout.conf settings
> allowing devs to reference a single, canonical source in order to
> support repo/profiles features.

> The current spec doesn't define many repo specific features leading to
> people jamming all sorts of conditional features in metadata/layout.conf
> via profile-formats and other entries, none of which is defined in the
> current spec.

> Mostly I'm asking because I'm tired of trying to support a pseudo-spec
> and am quite close to dropping pkgcore's support for the few
> profile-formats features it tries to enable. 

Why not make it a chapter of PMS? A separate document would presumably
imply having a repository API (RAPI?) decoupled from EAPI?

Ulrich

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 507 bytes --]

Re: [gentoo-dev] developing a separate repo spec

[Tim Harder]

On 2021-03-29 Mon 00:06, Ulrich Mueller wrote:
> Why not make it a chapter of PMS? A separate document would presumably
> imply having a repository API (RAPI?) decoupled from EAPI?

One reason is EAPI development often moves relatively slowly and many
potential repo spec features are probably simple enough to
discuss/implement at a quicker pace, at least initially.

That being said, if EAPI 8 isn't finalized most of the repo
functionality could be added to it if that approach is more agreeable.

Tim

Re: [gentoo-dev] developing a separate repo spec

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1001 bytes --]

>>>>> On Mon, 29 Mar 2021, Tim Harder wrote:

> One reason is EAPI development often moves relatively slowly and many
> potential repo spec features are probably simple enough to
> discuss/implement at a quicker pace, at least initially.

"Relatively slowly" is an understatement when it comes to repository
features. :) It is glacial for such changes, because we have to wait
for at least one year, in order not to break the upgrade path.

https://projects.gentoo.org/pms/7/pms.html#x1-320004.4 says:
"... a package manager must not attempt to use any repository whose
profiles directory requires an EAPI it does not support."

So yes, maybe we should have a separate spec for forward-compatible
repository features that are independent of EAPI. But I think that
incompatible changes won't be possible there and would have to reamin
in PMS. (For example, updating of package dependencies in profiles from
EAPI 0 to EAPI 5 was not forward compatible and required the one year
waiting period.)

Ulrich

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 507 bytes --]

Re: [gentoo-dev] developing a separate repo spec

[Tim Harder]

On 2021-03-30 Tue 02:18, Ulrich Mueller wrote:
> So yes, maybe we should have a separate spec for forward-compatible
> repository features that are independent of EAPI. But I think that
> incompatible changes won't be possible there and would have to reamin
> in PMS. (For example, updating of package dependencies in profiles from
> EAPI 0 to EAPI 5 was not forward compatible and required the one year
> waiting period.)

My main point is if users expect repos leveraging these features to work
with most tools it would be helpful to document them in a more
canonical, visible location than man pages and probably discuss them
more visibly as well. If they were truly optional features it wouldn't
be as much of an issue, but an increasing number of complex overlays
assume a minimum of portage-1/portage-2 profile-formats features being
readily available.

Furthermore, I don't think the current spec even mentions the
metadata/layout.conf file (and its semi-standard fields) and only
passingly mentions overlays but has no details about them. Getting more
of that in an official document would help devs know what they have to
implement to support current repo/overlay functionality.

Finally, pinning repo features to a standardized version allows tools to
more readily report why they won't work when failing to meet the repo's
required EAPI/RAPI instead of the semi-random errors that will often
occur during unimplemented usage.

Tim