Is there an easy way to check my USE flags for validity?

[RayDude]

You know, over the years USE flags come and go. I add one that was asked for and years later it disappears, but it's still in my make.conf.

Is there an easy way to validate my USE flags?

[Naib]

one way is to check the output of emerge --sync with and without your customisation

1. emerge --info | grep -oP 'USE="\K[^"]+'
2. edit make.conf to comment out USE=
3. emerge --info | grep -oP 'USE="\K[^"]+'

compare output.

Where flags remain they are being set by the profile and thus can be removed from your make.conf

[alamahant]

I just wrote a few commands.
Try something like

Code: Select all

myUSE=$(grep 'USE=".*"' /etc/portage/make.conf | tr -d '#USE="-')
myARR=( $myUSE )
#echo ${myARR[@]}
for i in ${myARR[@]};do
quse $i > /dev/null && echo $i seems valid  ||  echo $i seems invalid
done

[CaptainBlood]

IIRC app-portage/portpeek allows that.
"portpeek -ar" allows to check without any edit.

Thks 4 ur attention, interest & support.

[Goverp]

RayDude and CaptainBlood, thanks for the question and answer. I'd forgotten portpeek, and running it shows a lot of cruft in my setup.

[logrusx]

You know, over the years USE flags come and go. I add one that was asked for and years later it disappears, but it's still in my make.conf.

Is there an easy way to validate my USE flags?

It is not a good idea to put use flags in make.conf. My USE var in make.conf contains exactly 3 entries at the moment, all of them with - in front. Inspired by your post I reviewed them and concluded I didn't need another 5 of them, one being -cdr which turned out to not be a global one, having a different meaning for one package. The rest are all in /etc/portage/package.use

Keep them in /etc/portage/package.use, this way you'll know they won't affect other packages.

Best Regards,
Georgi

[CaptainBlood]

app-portage/portpeek maintains /etc/portage/package.*
I don't recall it will do anything to make.conf.
It should be easy to check adding a dummy flag to USE="..." in /etc/portage/make.conf

Thks 4 ur attention, interest & support.

[RayDude]

It is not a good idea to put use flags in make.conf. My USE var in make.conf contains exactly 3 entries at the moment, all of them with - in front. Inspired by your post I reviewed them and concluded I didn't need another 5 of them, one being -cdr which turned out to not be a global one, having a different meaning for one package. The rest are all in /etc/portage/package.use

Keep them in /etc/portage/package.use, this way you'll know they won't affect other packages.

Best Regards,
Georgi

Hi Georgi.

You are not the first to tell me that.

However, it seems ridiculous to list qt5 for every package that needs it in package.use.

Is there some usage model of USE that I don't know about?

I mean, do you really have no global USE in your make.conf?

I've been using Gentoo since the early 2000s when global use was the norm. (at least I thought it was).

I don't mean to imply that I don't use package.use, I do:

Code: Select all

lenny ~ # ls /etc/portage/package.use/
avahi   cross-aarch64-unknown-linux-gnu  freetype     libdrm       libsdl2   pulseaudio    qtpositioning  zlib
boost   dnsmasq                          gnutls       libpcre2     libvpx    pyside2       spice-gtk
chrony  ffmpeg                           kicad        libplacebo   nettle    qemu          texlive-core
cogl    file                             libdbusmenu  libreoffice  pipewire  qtmultimedia  wxGTK

How do I learn this "new to me" method of setting up USE variable?

[RayDude]

app-portage/portpeek maintains /etc/portage/package.*
I don't recall it will do anything in make.conf
It should be easy to check adding a dummy flag to USE="..." in /etc/portage/make.conf

Thks 4 ur attention, interest & support.

Thanks for telling me about portpeek. I ran it and am getting reams of errors.

It's too bad it ignores the global USE in make.conf.

It looks like I have to learn a new way to set my USE flags...

[RayDude]

I just wrote a few commands.
Try something like

Code: Select all

myUSE=$(grep 'USE=".*"' /etc/portage/make.conf | tr -d '#USE="-')
myARR=( $myUSE )
#echo ${myARR[@]}
for i in ${myARR[@]};do
quse $i > /dev/null && echo $i seems valid  ||  echo $i seems invalid
done

Thanks much!

I tweaked your script a bit, stealing from another reply in this thread:

Code: Select all

#!/bin/bash
myUSE=$(emerge --info | grep -oP 'USE="\K[^"]+')
myARR=( $myUSE )
#echo "myuse is ${myARR[@]}"
for i in ${myARR[@]};do
quse $i > /dev/null ||  echo $i seems invalid
done

Update: This is the result of my optimized USE

Code: Select all

64bit X a52 aac aalib acl acpi activities alsa amd64 ao aspell audio audiofile autostart avahi avi bash-completion bittorrent bluetooth bluray boost botan branding bzip2 cairo caps cdda cddb cdio cdparanoia cdr cdrom cdsound cec cgi clang cleartype cli cmake connection-sharing corefonts crypt css csv cups curl cxx dbus declarative device-mapper dri dts dv dvd dvdr egl elogind encode exif extras faac faad fat fax fbcon ffmpeg fftw fits flac fontconfig fontforge fortran ftp fuse games gd gdbm gecko gif gimp git glib gnome gphoto2 gpm gtk gtk2 gui hal hpcups hpijs html http httpd iconv icu id3 id3tag imagecache imap inotify iproute2 ipv6 irda ithreads jack jadetex java jpeg jpeg2k kde kwallet lame lcms libass libnotify libtirpc live logrotate logviewer lua lzo mad maildir matroska mikmod mim minizip mjpeg mng mod modplug mozilla mp3 mp4 mpd mpeg mplayer multilib multimedia musicbrainz mysql ncurses net network networkmanager nfs nfsv4 nftables nls nptl nsplugin nss ogg ogg123 ogm openal opengl openmp oxygen pam pango pcre pdf perl phonon php pipewire plasma png policykit posix postscript ppds profile pulseaudio pvr python qemu qml qt5 quicktime rar raw rdp readline real rendering resolvconf rtmp rtsp sasl scanner screencast sdl sdl-image seccomp semantic-desktop server session sftp sms sound spell split-usr sql ssl startup-notification stream suid svg syslog taglib tcl test-rust theora thesaurus threads tidy tiff tinfo tk truetype twolame udev udisks unicode unzip upnp upower usb v4l v4l2 vcd vhost-net vhosts video vnc vorbis vpx vulkan wav wavpack wayland webcam webserver widgets wma wxwidgets x264 x265 xattr xcb xcomposite xft xml xml2 xmltv xv xvid yahoo zeroconf zip zlib

Odd. It finds USE amd64, yet that is not anywhere in my /etc/portage folder and it reports:

"amd64 seems invalid"

[RayDude]

I tweaked the script to generate the optimized USE. Now it's just a copy and paste.

Code: Select all

#!/bin/bash
myUSE=$(emerge --info | grep -oP 'USE="\K[^"]+')
myARR=( $myUSE )
#echo "initial USE = ${myARR[@]}"
for i in ${myARR[@]};do
quse $i > /dev/null || myUSE=${myUSE//$i/}
done
echo "optimized USE = $(echo $myUSE | xargs)"

Oh, I just realized it removes negative USE flags...

[Hu]

However, it seems ridiculous to list qt5 for every package that needs it in package.use.

Is there some usage model of USE that I don't know about?

Per man portage, you can use wildcards in package.use. In the extreme case, you can write */* doc to enable USE=doc on everything, as if you had USE="doc" in make.conf. That is arguably slightly better than putting it in make.conf, since it means all your settings are in one place (package.use) instead of split between that and make.conf. You can also do less extreme globs, like games-action/* doc to install documentation for all your games, but not for any of your development libraries.

[logrusx]

I mean, do you really have no global USE in your make.conf?

I have. -qt5

Some things will get sorted out once you emerge them with the desired use flag. For example I use wayland and I had it in make.conf. However after removing it, portage didn't offer me any use change. I also have a couple of +qt5 packages I emerged with USE="qt5" on the command line. They stay like that despite global -qt5 because of what depends on them to be [qt5].

But with my statement I addressed this particular statement:

I add one that was asked for

This is not the way to go. When you're being asked for something, by default you add it in package.use. Of course you add things like qt5 in make.conf unless it's about a couple of packages. But that usually happens when you've already emerged those packages with the use flag disabled. If they were new to emerge, portage would've emerged them with the appropriate use flags. For cases like that I use USE=... on the command line. Portage won't do it on its own otherwise because it doesn't know what you want. But when you instruct it to do so it'll keep the settings as they are to satisfy the dependency graph.

For example, consider wine. Would you enable abi_86_32 globally and recompile everything? I wouldn't and in fact I didn't. I put everything that wine required to be [abi_x86_32] in a separate file.

Best Regards,
Georgi

[RayDude]

This is not the way to go. When you're being asked for something, by default you add it in package.use.

When portage asks me to add a USE for a package requirement, I always put it in /etc/portage/package.use/

I'm just not sure how I should transition my global USE to package.use.

Do I start with the packages that are currently building with a particular global USE?

Can I just do the top level and will the rest automagically add it?

I hate to experiment with this stuff because I rather like how stable my Gentoo has gotten.

[RayDude]

However, it seems ridiculous to list qt5 for every package that needs it in package.use.

Is there some usage model of USE that I don't know about?

Per man portage, you can use wildcards in package.use. In the extreme case, you can write */* doc to enable USE=doc on everything, as if you had USE="doc" in make.conf. That is arguably slightly better than putting it in make.conf, since it means all your settings are in one place (package.use) instead of split between that and make.conf. You can also do less extreme globs, like games-action/* doc to install documentation for all your games, but not for any of your development libraries.

I get what you are saying, but I don't understand the advantage of putting it in package.use as a */* versus in make.conf as a global.

doc is not really a good example because global USE="doc" is clearly overkill. But global "qt5" or "nfs" makes a lot more sense.

Again. I'm just not understanding the underlying principals for using USE variables.

[logrusx]

I'm just not sure how I should transition my global USE to package.use.

Start by commenting out the USE line in your make.conf and run emerge -DUav @world, see where it goes from there. For example I had added vaapi and vdpau in my make.conf and when I commented it out, it turned out only 4 packages in total were affected.

If it's too much to handle at once, start be commenting out use flags one by one or in groups. For example, comment out half the use flags and see where it goes.

Again. I'm just not understanding the underlying principals for using USE variables.

What do you mean by that?

Best Regards,
Georgi

[RayDude]

I'm just not sure how I should transition my global USE to package.use.

Start by commenting out the USE line in your make.conf and run emerge -DUav @world, see where it goes from there. For example I had added vaapi and vdpau in my make.conf and when I commented it out, it turned out only 4 packages in total were affected.

If it's too much to handle at once, start be commenting out use flags one by one or in groups. For example, comment out half the use flags and see where it goes.

Again. I'm just not understanding the underlying principals for using USE variables.

What do you mean by that?

Best Regards,
Georgi

Okay. I'll do that when I have some free time.

To me, USE is set to tell Gentoo what options I want for building the world. Things like plasma, wayland, alsa, etc. That's why USE was set in the make.conf file, right?

If you guys are telling me that I should control the USE on a per package basis, the implication is that USE variables are more package specific than system generic.

What is the disadvantage to setting USE in make.conf? Why is that bad?

[pietinger]

RayDude,

A (very) long time ago it was only possible to set the use flags in make.conf. But this has a disadvantage: If a certain use-flag is understood by several applications, but should not apply to all of them, then you would still have to use different names ... mysql1 mysql2 mysql3 ... not very elegant. So Gentoo has created the possibility to allow use-flags only for a specific application.

The best example where you really need it is: "static". You don't want to build all applications this way, but if you need "busybox" for your initramfs you probably want to build it WITH "static".
(Example: https://wiki.gentoo.org/wiki/Early_User ... quirements )

For all use-flags that apply globally, you can still set them in make.conf (I do it this way too).

[RayDude]

RayDude,

A (very) long time ago it was only possible to set the use flags in make.conf. But this has a disadvantage: If a certain use-flag is understood by several applications, but should not apply to all of them, then you would still have to use different names ... mysql1 mysql2 mysql3 ... not very elegant. So Gentoo has created the possibility to allow use-flags only for a specific application.

The best example where you really need it is: "static". You don't want to build all applications this way, but if you need "busybox" for your initramfs you probably want to build it WITH "static".
(Example: https://wiki.gentoo.org/wiki/Early_User ... quirements )

For all use-flags that apply globally, you can still set them in make.conf (I do it this way too).

Thanks.

That makes sense. Globals can still be set in make.conf. That's basically what I do now, but I have a lot of flags set as globals and perhaps I shouldn't.

[logrusx]

To me, USE is set to tell Gentoo what options I want for building the world. Things like plasma, wayland, alsa, etc. That's why USE was set in the make.conf file, right?

If you guys are telling me that I should control the USE on a per package basis, the implication is that USE variables are more package specific than system generic.

Use flags are not system generic. I'm not sure if they ever were. I think back when I used Gentoo before 2010, make.conf was still the only place to set them, but they were not system generic, they were applied to individual packages. They control build configuration options. They control dependencies. For example when you enable gtk4 on something it'll require gtk4 to be installed and will link against it. Think the options you pass to configure scripts. They can also control other tasks in the build/install process. They can control application of patches for example. Portage takes actions according to their presence.

A use flag is considered to be global if it's meaning is consistent all across the packages which have it and it affects at least several packages, I don't think there's an explicitly set number, but I remember seeing the number 4 in discussions.

What is the disadvantage to setting USE in make.conf? Why is that bad?

The disadvantage is for example you asking how to clean them Not remembering why certain use flag exists at all. When you have it in package.use, you at leas know which package needed it.

But more importantly, as I mentioned above, it can be understood differently by different packages. For example the cdr flag I mentioned. I had set it globally disabled because it meant CD-R back when I installed the system I used as a prototype for the current one and yesterday I cleaned it up because it meant CorelDraw files for inkscape.

You can also read https://wiki.gentoo.org/wiki/USE_flag.

Best Regards,
Georgi

[szatox]

They control dependencies. For example when you enable gtk4 on something it'll require gtk4 to be installed and will link against it.

Yeah, so once you enable gtk4 for one package on your system it pulls gtk4 in. At this point, it kinda makes sense to let all other packages that can use gtk4 to link against it too, don't you think?
Packages which can't use gtk4 will be unaffected anyway, right?

I have a few dozens of use flags in my make.conf. Most of them _could_ probably go in package.use instead, but there is no harm in having them in one place.
Things that do actually go to package.use are mostly flags I put there to resolve some conflicts, since in general if I have a library installed, I probably want to use it, and if I don't use it, I don't want it installed.
"Static" is a pretty good example of a flag that belongs to package.use though; it is sometimes necessary because "reasons", but it also makes things "worse", so we know we don't want it enabled globally just because of one exception.

[logrusx]

They control dependencies. For example when you enable gtk4 on something it'll require gtk4 to be installed and will link against it.

Yeah, so once you enable gtk4 for one package on your system it pulls gtk4 in. At this point, it kinda makes sense to let all other packages that can use gtk4 to link against it too, don't you think?

If using gtk4 makes sense, it's already the default. If you want to make it global for whatever reason - go ahead. Guaranteed, such an approach will bring you surprises.

How you do it is your own preference which does not necessarily make it right or wrong.

Best Regards,
Georgi

p.s. that sentence is taken out of context. It was intended to illustrate what I was talking about in the precious sentences.

[Hu]

As a counterexample with regard to gtk+, at one time net-analyzer/nmap accepted USE=gtk to build a GUI, in addition to the CLI. For users who only need the CLI, disabling USE=gtk skipped building a program they would not use. It looks like it no longer recognizes that flag. I have not used nmap since before that was changed, so I only noticed this removal when writing this post.

[logrusx]

As a counterexample with regard to gtk+, at one time net-analyzer/nmap accepted USE=gtk to build a GUI, in addition to the CLI. For users who only need the CLI, disabling USE=gtk skipped building a program they would not use. It looks like it no longer recognizes that flag. I have not used nmap since before that was changed, so I only noticed this removal when writing this post.

Code: Select all

- - zenmap                          : Install the GTK+ based nmap GUI, zenmap

Maybe it changed?

Best Regards,
Georgi

[Hu]

I have an old entry in package.use to disable USE=gtk on nmap. However, looking at the gentoo.git history, I cannot find where this ever would have worked, so it must have been changed prior to the import into git in 2015. I suppose I need to clean out old entries.