See tracker bug 350792. virtual/os-headers packages: sys-freebsd/freebsd-lib sys-kernel/linux-headers Please convert to a new-style virtual. Notes: - Keywords for the packages are mutually exclusive, so I think that neither blockers, nor USE_EXPAND logic (like "kernel_foo? ( some-cat/foo-headers )") are needed here. - Not sure what needs to be done for prefix. Maybe prefix profiles could simply add the new-style virtual to package.provided?
(In reply to comment #0) > - Not sure what needs to be done for prefix. Maybe prefix profiles could > simply add the new-style virtual to package.provided? Or, even simpler, the virtual could depend on: RDEPEND="!prefix? ( || ( sys-kernel/linux-headers sys-freebsd/freebsd-lib ) )" Unless I'm missing something, there would be no need for package.provided.
i dont think works. look at the prefix profiles ... they have many things encoded in there for virtual/os-headers.
(In reply to comment #2) > i dont think works. look at the prefix profiles ... they have many things > encoded in there for virtual/os-headers. Right. The typical scheme is (e.g. in profiles/prefix/darwin) that they have a line like: virtual/os-headers sys-darwin/libsystem in their virtuals file. But sys-darwin/libsystem isn't a real package and occurs only in the profile's package.provided file. @Prefix team: Could you please comment? Would such trickery still be needed with a new-style virtual (which could honour the "prefix" USE flag)?
as far as I remember, at some time in the past, portage required virtual/os-headers and virtual/libc to exist This makes sense in a real Gentoo Linux world, but doesn't in the Gentoo Prefix case where one is running on top of another OS. We simply used package.provided to "satisfy" the requirement for both virtuals. Nowadays, Portage itself doesn't barf any more when both are missing. virtual/libc is rarely used in the tree any more, which is good for us, since that means no missing dependency. I don't think I've encountered virtual/os-headers in the tree, ever, so I guess it can go as well.
(In reply to comment #3) > @Prefix team: Could you please comment? Would such trickery still be needed > with a new-style virtual (which could honour the "prefix" USE flag)? We don't need any specifics, by the way. As long as the virtual is satisfied (a generic package (host-libc, host-osheaders) if necessary is enough. There is no such logic that depends on the names and versions that are encoded in package.provided.
(In reply to comment #5) > We don't need any specifics, by the way. As long as the virtual is satisfied > (a generic package (host-libc, host-osheaders) if necessary is enough. You mean, change the RDEPEND in comment #1 to something like: RDEPEND="!prefix? ( || ( sys-kernel/linux-headers sys-freebsd/freebsd-lib ) ) prefix? ( || ( sys-foo/foo-headers sys-bar/bar-headers ... )" with sys-foo/foo-headers etc. in package.provided? I still don't see for what the "prefix? ( )" part would be needed, because it doesn't pull in any real packages. Am I missing something?
I'd rather omit the prefix? ( ... ) bit as well, like comment #1
Didn't follow the whole discussion, just to note I do have this in some package here: RDEPEND=" kerberos? ( || ( app-crypt/mit-krb5 sys-winnt/libc ) ) " On Windows it uses GSSAPI (IIRC), while mit-krb5 (no winnt keyword) elsewhere. How would I write that without creating another virtual/kerberos? While disliking negations, the only thing I can imagine for now is: RDEPEND=" kerberos? ( || ( !elibc_Winnt? ( app-crypt/mit-krb5 ) ) ) "
Created attachment 268863 [details] os-headers-0.ebuild for review (In reply to comment #7) > I'd rather omit the prefix? ( ... ) bit as well, like comment #1 Let's go with that, then. Please review attached ebuild. KEYWORDS are derived from reverse dependencies of virtual/os-headers in gentoo-x86 and prefix trees.
looks good to me, thanks for your work
(In reply to comment #8) > Didn't follow the whole discussion, just to note I do have this in some > package here: > > RDEPEND=" > kerberos? ( > || ( > app-crypt/mit-krb5 > sys-winnt/libc > ) > ) > " That's only loosely related to this bug. The new virtual/os-headers wouldn't need sys-winnt/libc (and its friends in other profiles) any more, but this doesn't necessarily imply that these packages should be removed from package.provided. > While disliking negations, the only thing I can imagine for now is: > RDEPEND=" > kerberos? ( > || ( > !elibc_Winnt? ( > app-crypt/mit-krb5 > ) > ) > ) > " Hm, if elibc_Winnt evaluates to true, then you end up with an empty || ( ) group. Better rewrite the above as follows: kerberos? ( !elibc_Winnt? ( app-crypt/mit-krb5 ) ) Otherwise, I don't see anything wrong with it.
(In reply to comment #9) > Please review attached ebuild. KEYWORDS are derived from reverse dependencies > of virtual/os-headers in gentoo-x86 and prefix trees. Shouldn't it contain /any/ keyword found in arch.list? (stable for archs doing stable keywords, unstable otherways) (In reply to comment #11) > kerberos? ( > !elibc_Winnt? ( app-crypt/mit-krb5 ) > ) > > Otherwise, I don't see anything wrong with it. fine.
(In reply to comment #12) > > KEYWORDS are derived from reverse dependencies of virtual/os-headers in > > gentoo-x86 and prefix trees. > > Shouldn't it contain /any/ keyword found in arch.list? Not sure. The keywords derived from reverse dependencies turned out to be the same ones as in virtual/editor. I took this as an indication that it must be right. ;) The missing(?) keywords are: ~x86-cygwin ~sparc64-freebsd ~mips-irix ~arm-linux ~x86-netbsd ~ppc-openbsd ~x64-openbsd ~x86-openbsd ~x86-winnt Prefix team, please decide if some or all of them should be added.
They should be missing, IMO, as there are no ebuilds keyworded with those keywords (and there is no intention to do so in the forseeable future).
I just see that kernel-2.eclass does the following for linux-headers: if [[ ${CTARGET} = ${CHOST} ]]; then DEPEND="!virtual/os-headers" PROVIDE="virtual/os-headers" SLOT="0" else SLOT="${CTARGET}" fi (Which breaks the metadata cache, BTW.) Should the virtual depend on sys-kernel/linux-headers:0 to be on the safe side? This would imply EAPI=1.
New virtual committed, profiles and ebuilds updated.
