Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 806592 - [Future EAPI] ECLASS_REVISION and autogenerated ebuild microrevisions
Summary: [Future EAPI] ECLASS_REVISION and autogenerated ebuild microrevisions
Status: CONFIRMED
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: PMS/EAPI (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: PMS/EAPI
URL:
Whiteboard: feasible-for-next-eapi
Keywords:
Depends on:
Blocks: future-eapi
  Show dependency tree
 
Reported: 2021-08-05 18:54 UTC by Andreas K. Hüttel
Modified: 2021-08-07 10:15 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas K. Hüttel archtester gentoo-dev 2021-08-05 18:54:14 UTC
As discussed on IRC... proposal for EAPI=9

An eclass can define a variable   
ECLASS_REVISION
assigned to a positive integer. If the variable is not defined, it defaults to 0.

Together with changes to an eclass, this variable should be increased by 1 whenever the outward-facing interface of the eclass, as, e.g., in particular generated dependency strings change. It must never be decreased.

The package manager shall track the revisions of all eclasses used when sourcing an ebuild. From these it calculates a microrevision value and associates it with the ebuild and eventually with the installed package or the binary package. 

A possible calclulation method for the microrevision would be the sum of all eclass revisions.

The microrevision is taken into account in version comparisons, as level below the ebuild revision. In particular, an increased microrevision triggers an upgrade-like rebuild.
 
Since ebuild microrevisions are in general autogenerated and invisible, there is no way to depend on a specific microrevision.
= in dependencies treats different microrevisions as equal.
Comment 1 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2021-08-05 19:04:20 UTC
(In reply to Andreas K. Hüttel from comment #0)
> As discussed on IRC... proposal for EAPI=9
> 
> An eclass can define a variable   
> ECLASS_REVISION
> assigned to a positive integer. If the variable is not defined, it defaults
> to 0.

Nit: the default value doesn't fit in the defined value range.
Comment 2 Andreas K. Hüttel archtester gentoo-dev 2021-08-05 19:12:20 UTC
As for what this is good for... here's an example.

perl-module.eclass adds to each package a dependency on dev-lang/perl
Now imagine that the precise dependency string needs to be changed. Do we really want to revbump 1600 packages without changes then, so the new depstring makes its way into local installed package databases?

In the past, the kde eclasses had similar functions, e.g., adding a minimal Qt version - and here the same problem arises.

And probably many more cases...
Comment 3 Andreas K. Hüttel archtester gentoo-dev 2021-08-05 19:12:49 UTC
(In reply to Michał Górny from comment #1)
> (In reply to Andreas K. Hüttel from comment #0)
> > As discussed on IRC... proposal for EAPI=9
> > 
> > An eclass can define a variable   
> > ECLASS_REVISION
> > assigned to a positive integer. If the variable is not defined, it defaults
> > to 0.
> 
> Nit: the default value doesn't fit in the defined value range.

Well, it is smaller than any assignable value. So assigning a first value always increases!
Comment 4 Ulrich Müller gentoo-dev 2021-08-05 19:36:44 UTC
(In reply to Michał Górny from comment #1)
> (In reply to Andreas K. Hüttel from comment #0)
> > As discussed on IRC... proposal for EAPI=9
> > 
> > An eclass can define a variable   
> > ECLASS_REVISION
> > assigned to a positive integer. If the variable is not defined, it defaults
> > to 0.
> 
> Nit: the default value doesn't fit in the defined value range.

I tend to agree with mgorny here. There's no good reason to disallow an assignment of 0 to the variable. That would also be consistent with ebuild revisions, where an explicit -r0 is allowed.

If we followed the language used elsewhere in the spec, we would say "unsigned integer".