According to https://packages.gentoo.org/useflags/egl this flag enable egl support for package x11-libs/libva But in https://packages.gentoo.org/packages/x11-libs/libva there is no egl flag, neither local or global ???
<x11-libs/libva-2.0.0 has an egl use flag. >=x11-libs/libva-2.0.0 does not because upstream dropped egl support (which, as far as I can tell, nothing in tree uses anyways): https://github.com/01org/libva/releases/tag/2.0.0 So what is the issue?
The pages make reference to different version of the package ? AFAIKU, - if latest release lead, x11-libs/libva should be removed from https://packages.gentoo.org/useflags/egl; - if not, https://packages.gentoo.org/packages/x11-libs/libva should add egl flag; Or maybe should be added somehow the reference release on both pages...
The data model says we care about what is in metadata.xml Metadata.xml for libva lists 'egl' which is why its listed in: https://packages.gentoo.org/useflags/egl The question is why does https://packages.gentoo.org/packages/x11-libs/libva not list it? It should be using the same data model.
(In reply to Alec Warner from comment #3) > The data model says we care about what is in metadata.xml > > Metadata.xml for libva lists 'egl' which is why its listed in: > https://packages.gentoo.org/useflags/egl > > The question is why does https://packages.gentoo.org/packages/x11-libs/libva > not list it? It should be using the same data model. the answer is we double store the same data with two different data models and it entirely depends on which package instance is used to render the package page.
(In reply to Alec Warner from comment #4) > (In reply to Alec Warner from comment #3) > > The data model says we care about what is in metadata.xml > > > > Metadata.xml for libva lists 'egl' which is why its listed in: > > https://packages.gentoo.org/useflags/egl > > > > The question is why does https://packages.gentoo.org/packages/x11-libs/libva > > not list it? It should be using the same data model. > > the answer is we double store the same data with two different data models > and it entirely depends on which package instance is used to render the > package page. So I think ultimately we store in the useflags index, a mapping of useflag => package. So in theory we could write a query: Useflag.search( query: { bool: { term: { match_all: { package: atom } } } }) This would, for a given package, pull the use flags from the Useflag index. We can then display these on the package overview, and avoid the double model problem. This means that users may try to enable a flag listed on p.g.o that is not relevant because it was dropped in a later ebuild version. I'm not sure there is anything p.g.o should do about this; this is a result of the confusing choices the distro made in data modelling.
We rewrote the entire application.
