It seems that the base USE flag is not being taken into account during compilation, and is not listed in equery either... Reproducible: Always Steps to Reproduce: 1.equery uses libreoffice 2.No "base" USE flag appears in the list 3.emerge -1av app-office/libreoffice Actual Results: After emerge completes (without errors), it prints: * Messages for package app-office/libreoffice-7.1.7.2: * If you plan to use Base application you must enable USE base. But adding 'base' to the use flags of app-office/libreoffice in package.use does not seem to have any effect: In the ebuild, it says: REQUIRED_USE="${PYTHON_REQUIRED_USE} base? ( firebird java ) ... so actually it should add dev-db/firebird to the list of software to install (dev-db/firebird is not installed here) - but it does not. Besides, it seems as though 'base' does not exist: equery uses libreoffice does not list it! Expected Results: equery uses libreoffice should list "base" as a USE flag for app-office/libreoffice and the addition of this flag should have as a consequence that firebird is installed too. It should also work as advertised, i.e. include "base" functionality into libreoffice. This seems related to https://forums.gentoo.org/viewtopic-p-8689094.html Looks like an ebuild bug to me...Other than that, app-office/libreoffice-7.1.7.2 is merged fine, so I refrain from further info first...
It has to exist or CI would fail. equery is not to be relied on for such matters. It is, however, masked: ``` $ grep -rsin "libreoffice.* base" profiles/ profiles/arch/amd64/package.use.stable.mask:37:app-office/libreoffice base profiles/arch/x86/package.use.mask:57:>=app-office/libreoffice-7 base java profiles/arch/x86/package.use.stable.mask:44:app-office/libreoffice base ``` You can try: `emerge -pvO libreoffice` to see the status of all flags. I expect to see '(-base)' to show it is masked (and therefore off).
(emege --info would be helpful here too)
(In reply to Sam James from comment #1) > You can try: `emerge -pvO libreoffice` to see the status of all flags. I > expect to see '(-base)' to show it is masked (and therefore off). Indeed it shows (-base). But then, there is no point in echoing that message at the end: If you plan to use Base application you must enable USE base. It just makes us run extra rounds for nothing. I have some old (25 years!) StarBase data somewhere (from StarOffice 5.2!), data that I had meticulously entered, only to lose them in the process of upgrading because StarBase support was dropped, then I think I read somewhere that StarBase support was re-enabled - and I thought maybe I could read them today with "Base"... :-) As far as the output of "emerge --info" is concerned, I thought it would be rather counter-productive, as I am in the middle of upgrade hell - after successfully finishing (did you see how? ;-)) https://bugs.gentoo.org/831325. But FWIW here it is, slightly redacted: Some info: Portage 3.0.28 (python 3.8.12-final-0, default/linux/amd64/17.1/hardened, gcc-11.2.0, glibc-2.30-r8, 5.4.168-gentoo x86_64) ================================================================= System uname: Linux-5.4.168-gentoo-x86_64-Intel-R-_Core-TM-_i7-6700HQ_CPU_@_2.60GHz-with-glibc2.2.5 Timestamp of repository gentoo: Sat, 22 Jan 2022 00:45:01 +0000 sh bash 5.1_p8 ld GNU ld (Gentoo 2.37_p1 p0) 2.37 app-misc/pax-utils: 1.2.5 app-shells/bash: 5.1_p8 dev-java/java-config: 2.2.0-r4 dev-lang/perl: 5.30.1 dev-lang/python: 2.7.18_p13, 3.6.10-r2, 3.7.7-r2, 3.8.12_p1-r1, 3.9.9-r1 dev-lang/rust: 1.41.1 dev-lang/rust-bin: 1.41.1 dev-util/cmake: 3.21.4 dev-util/meson: 0.60.3 sys-apps/baselayout: 2.7-r3 sys-apps/openrc: 0.42.1 sys-apps/sandbox: 2.25 sys-devel/autoconf: 2.13-r1, 2.69-r4 sys-devel/automake: 1.11.6-r3, 1.12.6, 1.13.4-r2, 1.14.1, 1.15.1-r2, 1.16.4 sys-devel/binutils: 2.33.1-r1, 2.37_p1 sys-devel/binutils-config: 5.4 sys-devel/clang: 7.0.0, 8.0.1, 9.0.1, 10.0.0 sys-devel/gcc: 7.5.0, 8.3.0-r1, 8.4.0, 9.3.0, 11.2.0 sys-devel/gcc-config: 2.5-r1 sys-devel/libtool: 2.4.6-r6 sys-devel/lld: 10.0.0 sys-devel/llvm: 7.0.0-r1, 8.0.1, 9.0.1, 10.0.0 sys-devel/make: 4.3 sys-kernel/linux-headers: 5.4-r1 (virtual/os-headers) sys-libs/glibc: 2.30-r8
(In reply to segmentation fault from comment #3) > Indeed it shows (-base). But then, there is no point in echoing that message > at the end: > > If you plan to use Base application you must enable USE base. There is, because that gives a stable user the chance to unmask the flag, of otherwise informs them that Base is essentially broken. (In reply to segmentation fault from comment #3) > It just makes us run extra rounds for nothing. No, not checking your portage output does. You do that using --ask.
(In reply to Andreas Sturmlechner from comment #4) > (In reply to segmentation fault from comment #3) > > Indeed it shows (-base). But then, there is no point in echoing that message > > at the end: > > > > If you plan to use Base application you must enable USE base. > There is, because that gives a stable user the chance to unmask the flag, of > otherwise informs them that Base is essentially broken. > > (In reply to segmentation fault from comment #3) > > It just makes us run extra rounds for nothing. > No, not checking your portage output does. You do that using --ask. May I suggest a somewhat user-friendlier way to do it: After the message "If you plan to do X you must enable USE flag Y." the ebuild, maybe through some standard eclass, could check the "status" of flag Y on user's system and print something like: flag Y is masked on your system - maybe through your profile or some setting of yours. Before you enable it in your package.use, you should unmask it. See (man page/web page or both) for details on how to do this. You could do this for every flag that you suggest the user might wish to "enable". In the ebuild you would use a function, say, print_flag_status_message(Y) after echoing a Y-specific message - and would be done about it. Sure, the user could become an expert in reading portage's "USE flag language" (I *always* use -a (--ask), but still struggle with th einterpretation of its output, as you see...) - but even if he should, you educate your users this way. And I don't think the changes in some eclass to facilitate this would be that dramatic. Even better, now that I think about it, would be specific information as to why and where it is masked/enabled/disabled/red/yellow/green/whatever: some extra option to emerge could make it print a detailed "legend", e.g.: (-base): Disabled in the ebuild, enabled in package.use, masked by profile in ... [my explanation is probably wrong, but you get the idea] Just a suggestion to think about. Thank you
No, that's backwards. Portage is facilitating ebuilds and metadata to gain information about use flags, which the user is able to query and gain knowledge about; it is not ebuilds facilitating portage to hand-hold the user. Yes, it is important to know how Portage works and what profiles are and how to deal with USE flags. The message can be amended with some more hints, but no sort of backwards magic is going to happen from the ebuild.
O.K. Thanks anyway. Feel free to close it.
