[gentoo-user] Highlight certain packages being upgraded

[Dale]

Howdy,

I was wondering.  Is there a way to highlight certain packages that are
about to be upgraded?  Example, I like to know when some larger packages
like Firefox, LOo, that excessively long qt package and a couple others
are going to be upgraded.  Some that are listed in the world file show
up in a darker green and are easier to see however, some are not. They
are dependencies of another package but I'd like to have them stick out
in the list of packages to be upgraded.  I don't recall ever seeing
anyone mention this as a feature of emerge or heard of a way to
configure such a thing either.  That said, it could be possible and just
not well known. 

I'd like to be able to have those packages show up as red or something
like that.  If it is possible. 

Thoughts?  Ever heard of such a thing?

Dale

:-)  :-) 

[John Blinka]

Post by Dale
Howdy,
I was wondering. Is there a way to highlight certain packages that are
about to be upgraded? Example, I like to know when some larger packages
like Firefox, LOo, that excessively long qt package and a couple others
are going to be upgraded. Some that are listed in the world file show
up in a darker green and are easier to see however, some are not. They
are dependencies of another package but I'd like to have them stick out
in the list of packages to be upgraded. I don't recall ever seeing
anyone mention this as a feature of emerge or heard of a way to
configure such a thing either. That said, it could be possible and just
not well known.
I'd like to be able to have those packages show up as red or something
like that. If it is possible.
Thoughts? Ever heard of such a thing?
Dale
:-) :-)

How about first making a list of all files needing to be rebuilt with
something like

emerge -pDuNv @world > builds

Then make a file “long” containing names of demanding builds like firefox
and qtwebengine, one to a line.

Finally, execute

grep -f long builds

which will print the names of those long builds if they’re due for
rebuilding or upgrading.

HTH

John Blinka

[Dr Rainer Woitok]

Dale,

Post by Dale
...
I was wondering.  Is there a way to highlight certain packages that are
about to be upgraded?  Example, I like to know when some larger packages
like Firefox, LOo, that excessively long qt package and a couple others
are going to be upgraded.

I simply don't know whether or not build-time related highlighting is
possible in native Portage. I retrieve that information by some script-
ing, which involves sending the output of "emerge --ask" to a log file,
and as soon as "emerge" asks whether to continue, running a script in
another terminal window which analyses this log file using "qlop" and
"gawk".

But to really ban several buld-time hogs from my rig, I added "-clang"
and "-llvm" to my global USE flags, added "dev-lang/rust" to directory
"package.mask/", causing "dev-lang/rust-bin" to be used when necessary,
and besides happily replaced "www-client/firefox" with its binary vari-
ant. I also tried this with "app-office/libreoffice", but sadly its bi-
nary variant does not support exporting to PDF, so I humbly returned to
"app-office/libreoffice" which here needs some three hours to build. If
you don't need this feature, I would recommend using its binary version,
too. Luckily, I don't have many "Qt" packages as dependencies, the lon-
gest build time of these is about 23 minutes here.

Sincerely,
Rainer

[Neil Bothwick]

I was wondering.  Is there a way to highlight certain packages that are
about to be upgraded?  Example, I like to know when some larger packages
like Firefox, LOo, that excessively long qt package and a couple others
are going to be upgraded.  Some that are listed in the world file show
up in a darker green and are easier to see however, some are not. They
are dependencies of another package but I'd like to have them stick out
in the list of packages to be upgraded.  I don't recall ever seeing
anyone mention this as a feature of emerge or heard of a way to
configure such a thing either.  That said, it could be possible and just
not well known. 

If your objective is to update your system without the long build times,
put the atoms of the relevant packages in a file and run

emerge --your-options --exclude "$(cat big-packages.txt)" @world

[Jack]

Post by Dale

Post by Neil Bothwick

Post by Dale
I was wondering.  Is there a way to highlight certain packages

that are

Post by Neil Bothwick

Post by Dale
about to be upgraded?  Example, I like to know when some larger

packages

Post by Neil Bothwick

Post by Dale
like Firefox, LOo, that excessively long qt package and a couple

others

Post by Neil Bothwick

Post by Dale
are going to be upgraded.  Some that are listed in the world file

show

Post by Neil Bothwick

Post by Dale
up in a darker green and are easier to see however, some are not.

They

Post by Neil Bothwick

Post by Dale
are dependencies of another package but I'd like to have them

stick out

Post by Neil Bothwick

Post by Dale
in the list of packages to be upgraded.  I don't recall ever seeing
anyone mention this as a feature of emerge or heard of a way to
configure such a thing either.  That said, it could be possible

and just

Post by Neil Bothwick

Post by Dale
not well known. 

If your objective is to update your system without the long build

times,

Post by Neil Bothwick
put the atoms of the relevant packages in a file and run

I'm just wanting certain packages to stand out more in the list emerge
spits out.  Some require a lot of memory, some have long build times,
some both of those and some require me to restart programs or do other
things.  I already check the changes in USE flags but they stick out
good since they are usually yellow or some other color.  I was curious
if I could set colors for certain packages without reinventing the
wheel.  While I don't recall hearing or seeing anything about it, I
thought it might be possible I just hadn't heard about a feature that
does this. 
Doesn't sound like there is a easy way to do this so I guess just
looking at each package name is the way to go for now. 

Using Neil's approach, you do the emerge with the excludes, so you know
there are no problem packages included. Then you run it again, without
the excludes, and all/most of what shows up will be those big/long
packages. No need to hunt through the first list, and the second list
will be much shorted and easier to review. Yes, it would be nice if
portage gave you a way to visually flag certain packages, but it's not
currently an option.

[Dale]

Post by Jack

Post by Dale

Post by Neil Bothwick

Post by Dale
I was wondering.  Is there a way to highlight certain packages

that are

Post by Neil Bothwick

Post by Dale
about to be upgraded?  Example, I like to know when some larger

packages

Post by Neil Bothwick

Post by Dale
like Firefox, LOo, that excessively long qt package and a couple

others

Post by Neil Bothwick

Post by Dale
are going to be upgraded.  Some that are listed in the world file

show

Post by Neil Bothwick

Post by Dale
up in a darker green and are easier to see however, some are not.

They

Post by Neil Bothwick

Post by Dale
are dependencies of another package but I'd like to have them

stick out

Post by Neil Bothwick

Post by Dale
in the list of packages to be upgraded.  I don't recall ever seeing
anyone mention this as a feature of emerge or heard of a way to
configure such a thing either.  That said, it could be possible

and just

Post by Neil Bothwick

Post by Dale
not well known. 

If your objective is to update your system without the long build

times,

Post by Neil Bothwick
put the atoms of the relevant packages in a file and run

I'm just wanting certain packages to stand out more in the list emerge
spits out.  Some require a lot of memory, some have long build times,
some both of those and some require me to restart programs or do other
things.  I already check the changes in USE flags but they stick out
good since they are usually yellow or some other color.  I was curious
if I could set colors for certain packages without reinventing the
wheel.  While I don't recall hearing or seeing anything about it, I
thought it might be possible I just hadn't heard about a feature that
does this. 
Doesn't sound like there is a easy way to do this so I guess just
looking at each package name is the way to go for now. 

Using Neil's approach, you do the emerge with the excludes, so you
know there are no problem packages included.  Then you run it again,
without the excludes, and all/most of what shows up will be those
big/long packages.  No need to hunt through the first list, and the
second list will be much shorted and easier to review.  Yes, it would
be nice if portage gave you a way to visually flag certain packages,
but it's not currently an option.

Thing is, some of the packages are dependencies of other packages. 
Excluding them will likely trigger other problems, such as packages not
being able to upgrade due to others being excluded.  Plus, I'd have to
run it twice and do two separate upgrades.  Usually, I start the upgrade
in a chroot, take a nap and it is done when I wake up.  I'd have to
interrupt my nap for the second set if it is split up. 

Having it highlight the packages so I can see them easier was a thought,
just not a good one.  :/ 

Oh well, we tried.  lol

Dale

:-)  :-) 

[Neil Bothwick]

Thing is, some of the packages are dependencies of other packages. 
Excluding them will likely trigger other problems, such as packages not
being able to upgrade due to others being excluded.  Plus, I'd have to
run it twice and do two separate upgrades.  Usually, I start the upgrade
in a chroot, take a nap and it is done when I wake up.  I'd have to
interrupt my nap for the second set if it is split up. 
Having it highlight the packages so I can see them easier was a thought,
just not a good one.  :/ 

But what would you do with the information? If you're just going to see
that there are slow packages there and then carry, what's the point. I
suppose you know you can have a longer nap :)

You could try piping emerge's output through sed to add colour codes
around the packages you want to highlight. How exactly you do this is
left as an exercise for the reader :P

[Dale]

Post by Neil Bothwick

Post by Dale
Thing is, some of the packages are dependencies of other packages. 
Excluding them will likely trigger other problems, such as packages not
being able to upgrade due to others being excluded.  Plus, I'd have to
run it twice and do two separate upgrades.  Usually, I start the upgrade
in a chroot, take a nap and it is done when I wake up.  I'd have to
interrupt my nap for the second set if it is split up. 
Having it highlight the packages so I can see them easier was a thought,
just not a good one.  :/ 

But what would you do with the information? If you're just going to see
that there are slow packages there and then carry, what's the point. I
suppose you know you can have a longer nap :)
You could try piping emerge's output through sed to add colour codes
around the packages you want to highlight. How exactly you do this is
left as an exercise for the reader :P

When I see certain packages, I know to close some of my Firefox profiles
if they require a lot of memory.  For some, I know I need to restart
that program/service.  For some, such as my video drivers, I know to
reload the modules after I logout.  What I do with the info depends on
which package it is.  I just make a mental note that certain things
needs to be done and I know to do them either before I start the upgrade
or after it is done. 

Just as a example, my overnight upgrade included nvidia drivers.  I
didn't see it so when I logged out, no X.  I usually see it but missed
it this time.  Having a way to easily set the colors would be easier but
having to repeat things, create files to scan, use tools I'm not
familiar with and such, that isn't easy.  I wanted to be able to see it
in the initial list, make a note of what packages I need to do things
for and then hit yes to continue.  Basically, I was hoping emerge had a
way to do this that isn't known to me.  After all, the thing all but
washes dishes already.  ROFL 

Maybe one day others will like this idea and one of them is willing to
add some code to emerge to do it.  Until then, I guess I'll just miss
one on occasion and have to scratch my head a couple times. 

Thanks to all.  Interesting ideas but generally over my head.  :/

Dale

:-)  :-) 

[Jack]

What about piping the output of emerge through 'tee' into a file.  You
can then grep that file for the package names you are interested in, and
they will clearly be highlighted.  True, you will need to look at the
portage output directly to decide whether or not to proceed, and then
separately at the grep of the same text to see if you need to take other
actions.

Post by Dale

Post by Neil Bothwick

Post by Dale
Thing is, some of the packages are dependencies of other packages.
Excluding them will likely trigger other problems, such as packages not
being able to upgrade due to others being excluded.  Plus, I'd have to
run it twice and do two separate upgrades.  Usually, I start the upgrade
in a chroot, take a nap and it is done when I wake up.  I'd have to
interrupt my nap for the second set if it is split up.
Having it highlight the packages so I can see them easier was a thought,
just not a good one.  :/

But what would you do with the information? If you're just going to see
that there are slow packages there and then carry, what's the point. I
suppose you know you can have a longer nap :)
You could try piping emerge's output through sed to add colour codes
around the packages you want to highlight. How exactly you do this is
left as an exercise for the reader :P

When I see certain packages, I know to close some of my Firefox profiles
if they require a lot of memory.  For some, I know I need to restart
that program/service.  For some, such as my video drivers, I know to
reload the modules after I logout.  What I do with the info depends on
which package it is.  I just make a mental note that certain things
needs to be done and I know to do them either before I start the upgrade
or after it is done.
Just as a example, my overnight upgrade included nvidia drivers.  I
didn't see it so when I logged out, no X.  I usually see it but missed
it this time.  Having a way to easily set the colors would be easier but
having to repeat things, create files to scan, use tools I'm not
familiar with and such, that isn't easy.  I wanted to be able to see it
in the initial list, make a note of what packages I need to do things
for and then hit yes to continue.  Basically, I was hoping emerge had a
way to do this that isn't known to me.  After all, the thing all but
washes dishes already.  ROFL
Maybe one day others will like this idea and one of them is willing to
add some code to emerge to do it.  Until then, I guess I'll just miss
one on occasion and have to scratch my head a couple times.
Thanks to all.  Interesting ideas but generally over my head.  :/
Dale
:-)  :-)

[Wol]

Post by Dale
Just as a example, my overnight upgrade included nvidia drivers.  I
didn't see it so when I logged out, no X.  I usually see it but missed
it this time.  Having a way to easily set the colors would be easier but
having to repeat things, create files to scan, use tools I'm not
familiar with and such, that isn't easy.  I wanted to be able to see it
in the initial list, make a note of what packages I need to do things
for and then hit yes to continue.  Basically, I was hoping emerge had a
way to do this that isn't known to me.  After all, the thing all but
washes dishes already.  ROFL
Maybe one day others will like this idea and one of them is willing to
add some code to emerge to do it.  Until then, I guess I'll just miss
one on occasion and have to scratch my head a couple times.
Thanks to all.  Interesting ideas but generally over my head.  :/

Something I saw elsewhere - why don't you put all of these programs into
a list like @system or @world. You can exclude these programs from an
"emerge @world".

I don't know whether these programs will be emerged as dependencies of
an "emerge @world", but if you want to know if they will be emerged, an
"emerge @... --pretend" will tell you.

So firstly, you know whether any of these programs are going to be
emerged. Secondly, you can emerge all the hogs in one go. And thirdly,
you you can emerge @world before or after.

So, I guess, if you don't exclude these hogs from @world then you can
just find out if they are going to be emerged (and emerge them first if
you want), or if you do exclude them from @world, you can emerge them
(to some extent at least) on your own timescale.

Cheers,
Wol

[Dale]

Post by Neil Bothwick

Post by Dale
I was wondering.  Is there a way to highlight certain packages that are
about to be upgraded?  Example, I like to know when some larger packages
like Firefox, LOo, that excessively long qt package and a couple others
are going to be upgraded.  Some that are listed in the world file show
up in a darker green and are easier to see however, some are not. They
are dependencies of another package but I'd like to have them stick out
in the list of packages to be upgraded.  I don't recall ever seeing
anyone mention this as a feature of emerge or heard of a way to
configure such a thing either.  That said, it could be possible and just
not well known. 

If your objective is to update your system without the long build times,
put the atoms of the relevant packages in a file and run

I'm just wanting certain packages to stand out more in the list emerge
spits out.  Some require a lot of memory, some have long build times,
some both of those and some require me to restart programs or do other
things.  I already check the changes in USE flags but they stick out
good since they are usually yellow or some other color.  I was curious
if I could set colors for certain packages without reinventing the
wheel.  While I don't recall hearing or seeing anything about it, I
thought it might be possible I just hadn't heard about a feature that
does this. 

Doesn't sound like there is a easy way to do this so I guess just
looking at each package name is the way to go for now. 

Dale

:-)  :-) 

[Dale]

Hello Dale,
I have reused the configuration file
"/etc/portage/package.env/no_tmpfs.conf"[1], which already contains a
list of packages, which need hours to compile.
-Ramon
[1]
https://wiki.gentoo.org/wiki/Portage_TMPDIR_on_tmpfs#Per-package_choices_at_compile_time

I need more than just packages that take a while to compile. I need a
list of packages that require large amounts of memory, needs restarting
after upgrade is done and other things.  I already use notmpfs on a few
packages.  That works fine.  Things is, I need to know about other
packages for other reasons as well.  Upgrading nvidia is one.  It uses
little memory to upgrade but it does require the modules to be reloaded. 

Maybe one of these days. 

Dale

:-)  :-) 

[Neil Bothwick]

Post by Dale

I have reused the configuration file
"/etc/portage/package.env/no_tmpfs.conf"[1], which already contains a
list of packages, which need hours to compile.
-Ramon
[1]
https://wiki.gentoo.org/wiki/Portage_TMPDIR_on_tmpfs#Per-package_choices_at_compile_time

I need more than just packages that take a while to compile. I need a
list of packages that require large amounts of memory, needs restarting
after upgrade is done and other things.  I already use notmpfs on a few
packages.  That works fine.  Things is, I need to know about other
packages for other reasons as well.  Upgrading nvidia is one.  It uses
little memory to upgrade but it does require the modules to be
reloaded. 

You can do a lot with package.env, including sending notifications
to remind you to do this. I also run app-admin/needrestart after each
emerge to list any services that need restarting.

[Dale]

Post by Neil Bothwick

Post by Dale

I have reused the configuration file
"/etc/portage/package.env/no_tmpfs.conf"[1], which already contains a
list of packages, which need hours to compile.
-Ramon
[1]
https://wiki.gentoo.org/wiki/Portage_TMPDIR_on_tmpfs#Per-package_choices_at_compile_time

I need more than just packages that take a while to compile. I need a
list of packages that require large amounts of memory, needs restarting
after upgrade is done and other things.  I already use notmpfs on a few
packages.  That works fine.  Things is, I need to know about other
packages for other reasons as well.  Upgrading nvidia is one.  It uses
little memory to upgrade but it does require the modules to be reloaded. 

You can do a lot with package.env, including sending notifications
to remind you to do this. I also run app-admin/needrestart after each
emerge to list any services that need restarting.

I just wanted to be able to see them better in the output of emerge. 
Anything else just creates more work and consumes more time than it
saves.  Once I scan the list, I can hit yes and let it start.  If I see
Firefox, LOo or others, I close Firefox profiles, sometimes Seamonkey,
to free up memory.  If I see packages that are services, I know I need
to restart them, even if checkrestart doesn't show it.  If I see
mplayer, I know that if Smplayer moves to a new video in the playlist,
it will likely fail to start.  Some I just know I can take a nice
loooong nap.  What I do just depends on the package.  I just need it to
be easier to see in the list.  Nothing fancy, just easier to see. 

I use checkrestart still.  I tried needrestart but it does more than I
need.  I found checkrestart in a overlay and I just stuck with it. 
Heck, I still use the rc command, even tho it gripes each time I use
it.  lol 

Dale

:-)  :-) 

[Neil Bothwick]

I use checkrestart still.  I tried needrestart but it does more than I
need.

Just about every program on this computer does more than I need. What
counts is that they do all that I need :)

Have you looked at using sed to add extra colour codes to the output of
emerge?

[Dale]

Post by Neil Bothwick

Post by Dale
I use checkrestart still.  I tried needrestart but it does more than I
need.

Just about every program on this computer does more than I need. What
counts is that they do all that I need :)
Have you looked at using sed to add extra colour codes to the output of
emerge?

I don't know anything about sed.  Heck, it took me a long to to even get
started with grep.  ROFL

Dale

:-)  :-) 

[Neil Bothwick]

Post by Neil Bothwick
Just about every program on this computer does more than I need. What
counts is that they do all that I need :)
Have you looked at using sed to add extra colour codes to the output
of emerge?

I don't know anything about sed.  Heck, it took me a long to to even get
started with grep.  ROFL

Try this:

Create a file with the package atoms you want to highlight, one per
line, say packages.txt. Then run this command, you'll need to rerun it
each time you edit the packages list

awk '{print "s:\\("$0"\\):\\x1b[1;31m\\1:"}' packages.txt

|packages.script

Then run

emerge --options @world -p --color y | sed -f packages.script

It highlights any of the packages in your file in bright red. See
https://gist.github.com/fnky/458719343aabd01cfb17a3a4f7296797 for a list
of colour options.

[Neil Bothwick]

Post by Neil Bothwick
Then run
It highlights any of the packages in your file in bright red. See
https://gist.github.com/fnky/458719343aabd01cfb17a3a4f7296797 for a
list of colour options.

Like Wol's idea, that's a extra step.  I was wanting it to just do it
when running emerge -auDN world with no additional steps except creating
the file for the package list. 

That is the only extra step, unless you mean that you have to run with -p
to see the highlighted output. That takes a lot less time than you have
invested in this so far.

Actually, I've checked and you can run this with --ask instead or -p, so
no extra steps involved. The only limitation is that you don't see the
Y/n prompt at the end of the ask output. Create an alias to the command,
or wrap it in a script that also runs the sed command first and the
number of extra steps becomes exactly zero.

[Neil Bothwick]

Post by Neil Bothwick

Post by Neil Bothwick
Then run
It highlights any of the packages in your file in bright red. See
https://gist.github.com/fnky/458719343aabd01cfb17a3a4f7296797 for a
list of colour options.

Like Wol's idea, that's a extra step.  I was wanting it to just do it
when running emerge -auDN world with no additional steps except
creating the file for the package list. 

That is the only extra step, unless you mean that you have to run
with -p to see the highlighted output. That takes a lot less time
than you have invested in this so far.
Actually, I've checked and you can run this with --ask instead or -p,
so no extra steps involved. The only limitation is that you don't see
the Y/n prompt at the end of the ask output. Create an alias to the
command, or wrap it in a script that also runs the sed command first
and the number of extra steps becomes exactly zero.

And I have no clue how to do any of that.  Like I said, emerge just
isn't ready for anything like this.  I was hoping there may be some
option, config file or something that I can use to do this and it just
work.  I think if there was such a thing, someone would have mentioned
it long ago.  Maybe one day something like this will be added.  Then
again, maybe not. 

Just create the list of packages, copy and paste the commands and run the
emerge command I gave. You could add

alias myworld="emerge --options @world | sed -f /etc/portage/packages.script"

to your /etc/profile, then it's a one word command to get what you want.

[Nikos Chantziaras]

Post by Dale
that excessively long qt package

Off-topic, but just in case you mean qtwebengine, I was able to get rid
of it by putting "-webengine" in my USE flags. After a world update, a
depclean should then remove it from the system.

You might have to juggle a few other USE flags in specific packages to
make it happen though, I forgot. It's been a while.

[Dale]

Post by Nikos Chantziaras

Post by Dale
that excessively long qt package

Off-topic, but just in case you mean qtwebengine, I was able to get
rid of it by putting "-webengine" in my USE flags. After a world
update, a depclean should then remove it from the system.
You might have to juggle a few other USE flags in specific packages to
make it happen though, I forgot. It's been a while.

That's a idea but since everything works well enough, I don't mind the
compile times. After all, I nap while it does it anyway.  Someone else
may see that info and find it interesting tho.  Maybe someone with a
laptop or a really under-powered system.  I never thought about trying
to get rid of it.  I didn't know it was possible even. 

Thanks.

Dale

:-)  :-) 

[Michael]

Post by Dale

Post by Nikos Chantziaras

Post by Dale
that excessively long qt package

Off-topic, but just in case you mean qtwebengine, I was able to get
rid of it by putting "-webengine" in my USE flags. After a world
update, a depclean should then remove it from the system.
You might have to juggle a few other USE flags in specific packages to
make it happen though, I forgot. It's been a while.

That's a idea but since everything works well enough, I don't mind the
compile times. After all, I nap while it does it anyway. Someone else
may see that info and find it interesting tho. Maybe someone with a
laptop or a really under-powered system. I never thought about trying
to get rid of it. I didn't know it was possible even.
Thanks.
Dale
:-) :-)

Thanks for the tip, Nikos. I wouldn't mind trying this, because qtwebengine

Post by Dale

Post by Nikos Chantziaras

Post by Dale
Running pre-merge checks for dev-qt/qtwebengine-5.15.10_p20230623

* Checking for at least 20 GiB RAM ...
* Amount of main memory is insufficient, but amount
* of main memory combined with swap is sufficient.
* Build process may make computer very slow! [ ok ]
* Checking for at least 7 GiB disk space at "/var/tmp/portage/dev-qt/
qtwebengine-5.15.10_p20230623/temp" ... [ ok ]
* Checking for at least 150 MiB disk space at "/usr" ... [ ok ]

However, I wonder what will break if I were to do this:

$ euse -i webengine
global use flags (searching: webengine)
************************************************************
no matching entries found

local use flags (searching: webengine)
************************************************************
[- ] webengine
app-misc/recoll: Use dev-qt/qtwebengine for fancy result list display
[- ] 1.34.6-r1 [gentoo]
[- ] 1.35.0 [gentoo]

[- ] webengine
app-office/libalkimia: Enable online quotes using dev-qt/qtwebengine
[- ] (0/8) 8.1.1-r1 [gentoo]

[- ] webengine
app-text/kbibtex: Use dev-qt/qtwebengine for HTML previews
[- ] (5) 0.10.0 [gentoo]

[- ] webengine
dev-python/QtPy: Pull in QtWebEngine and QtWebEngineWidgets modules
[- ] 2.3.1 [gentoo]

[- ] webengine
dev-python/pyside2: Build QtWebEngine and QtWebEngineWidgets modules
[- ] 5.15.9 [gentoo]
[- ] 5.15.10 [gentoo]

[- ] webengine
dev-python/pyside6: Build QtWebEngine and QtWebEngineWidgets modules
[- ] 6.5.0 [gentoo]
[- ] 6.5.1.1 [gentoo]

[- ] webengine
dev-qt/qt-creator: Use dev-qt/qtwebengine to view documentation
[- ] 8.0.2 [gentoo]

[- ] webengine
dev-qt/qt-docs: Install documentation for dev-qt/qtwebengine
[- ] (5) 5.15.2_p202011130614 [gentoo]

[- ] webengine
kde-apps/kaccounts-providers: Enable Nextcloud KAccounts plugin using dev-
qt/qtwebengine
[+ B] (5) 22.12.3 [gentoo]
[+ B] (5) 23.04.2 [gentoo]
[+ B] (5) 23.04.3 [gentoo]

[- ] webengine
kde-apps/kdecore-meta: Enable www-client/falkon which depends on dev-qt/
qtwebengine
[+ B] (5) 22.12.3 [gentoo]
[+ B] (5) 23.04.2 [gentoo]
[+ B] (5) 23.04.3 [gentoo]

[- ] webengine
kde-apps/kdeedu-meta: Enable packages requiring dev-qt/qtwebengine
[+ B] (5) 22.12.3 [gentoo]
[+ B] (5) 23.04.2 [gentoo]
[+ B] (5) 23.04.3 [gentoo]

[- ] webengine
kde-apps/kdenetwork-meta: Enable support for Google Drive integration via
kde-misc/kio-gdrive
[+ B] (5) 22.12.3 [gentoo]
[+ B] (5) 23.04.2 [gentoo]
[+ B] (5) 23.04.3 [gentoo]

[- ] webengine
kde-apps/kdesdk-meta: Enable dev-util/kdevelop, requiring dev-qt/
qtwebengine
[- ] (5) 22.12.3 [gentoo]
[- ] (5) 23.04.2 [gentoo]
[- ] (5) 23.04.3 [gentoo]

[- ] webengine
kde-apps/kdeutils-meta: Enable kde-apps/kimagemapeditor, requiring dev-qt/
qtwebengine
[+ B] (5) 22.12.3 [gentoo]
[+ B] (5) 23.04.2 [gentoo]
[+ B] (5) 23.04.3 [gentoo]

[- ] webengine
kde-apps/marble: Use dev-qt/qtwebengine for embedded web browser
[+ B] (5/22.12) 22.12.3 [gentoo]
[+ B] (5/23.04) 23.04.2 [gentoo]
[+ B] (5/23.04) 23.04.3 [gentoo]

[- ] webengine
kde-plasma/discover: Enable webflow support using dev-qt/qtwebview and
dev-qt/qtwebengine instead of default URL handler
[- ] (5) 5.27.5-r1 [gentoo]
[- ] (5) 5.27.6 [gentoo]

[- ] webengine
kde-plasma/kdeplasma-addons: Enable dictionary and web browser applets
using
dev-qt/qtwebengine
[- ] (5) 5.27.5 [gentoo]
[- ] (5) 5.27.6 [gentoo]

[- ] webengine
kde-plasma/libksysguard: Enable display of detailed memory information
using
dev-qt/qtwebengine.
[- ] (5/9) 5.27.5 [gentoo]
[- ] (5/9) 5.27.6 [gentoo]

[- ] webengine
media-sound/musescore: Use dev-qt/qtwebengine for embedded web browser
[- ] 3.6.2-r1 [gentoo]
4.0.2 [gentoo]
[- ] 9999 [gentoo]

[- ] webengine
media-sound/supercollider: Enable the internal help system using
QtWebengine
[- ] 3.13.0 [gentoo]

[- ] webengine
net-im/psi: Enable themed, html-based chatlogs using dev-qt/qtwebengine
[- ] 1.5-r1 [gentoo]
[- ] 9999 [gentoo]

[- ] webengine
net-misc/nextcloud-client: Enable old Flow1 login using dev-qt/qtwebengine
[- ] 3.8.0 [gentoo]
[- ] 3.8.1 [gentoo]
[- ] 3.8.2-r1 [gentoo]

[- ] webengine
net-news/rssguard: Use dev-qt/qtwebengine for embedded web browser
[- ] 4.3.3 [gentoo]
[- ] 4.3.4 [gentoo]
[- ] 4.4.0 [gentoo]

[- ] webengine
net-p2p/ktorrent: Embedded search for torrents using dev-qt/qtwebengine
[+ B] (5) 22.12.3 [gentoo]
[+ B] (5) 23.04.2 [gentoo]
[+ B] (5) 23.04.3 [gentoo]

[- ] webengine
sci-astronomy/stellarium: Show online results about the selected star in
an embedded
window using dev-qt/qtwebengine
[- ] 23.1 [gentoo]

[- ] webengine
sci-geosciences/merkaartor: Enable dev-qt/qtwebengine in some plugins
[- ] 0.19.0-r1 [gentoo]
[- ] 9999 [gentoo]

[- ] webengine
sci-visualization/paraview: Add support for dev-qt/qtwebengine
[+ B] 5.11.1 [gentoo]

[Peter Humphrey]

Post by Nikos Chantziaras

Post by Dale
that excessively long qt package

Off-topic, but just in case you mean qtwebengine, I was able to get rid
of it by putting "-webengine" in my USE flags. After a world update, a
depclean should then remove it from the system.
You might have to juggle a few other USE flags in specific packages to
make it happen though, I forgot. It's been a while.

Nice idea, but it's not for me I'm afraid:

$ emerge -cvp qtwebengine

Calculating dependencies ... done!
dev-qt/qtwebengine-5.15.10_p20230623 pulled in by:
app-office/kalendar-23.04.3 requires >=dev-qt/qtwebengine-5.15.9:5
kde-apps/akregator-23.04.3 requires >=dev-qt/qtwebengine-5.15.9:5
kde-apps/grantlee-editor-23.04.3 requires >=dev-qt/
qtwebengine-5.15.9:5[widgets]
kde-apps/kaccounts-providers-23.04.3 requires >=dev-qt/
qtwebengine-5.15.9:5
kde-apps/kdepim-runtime-23.04.3 requires >=dev-qt/
qtwebengine-5.15.9:5[widgets]
kde-apps/kmail-23.04.3 requires >=dev-qt/qtwebengine-5.15.9:5[widgets]
kde-apps/kontact-23.04.3 requires >=dev-qt/qtwebengine-5.15.9:5[widgets]
kde-apps/libksieve-23.04.3 requires >=dev-qt/qtwebengine-5.15.9:5[widgets]
kde-apps/messagelib-23.04.3 requires >=dev-qt/
qtwebengine-5.15.9:5[widgets]
net-libs/signon-ui-0.15_p20171022-r1 requires dev-qt/qtwebengine:5
www-client/falkon-23.04.3 requires >=dev-qt/
qtwebengine-5.15.9:5=[widgets], >=dev-qt/qtwebengine-5.15.9:5/5.15=[widgets]

[Matt Connell]

Post by Nikos Chantziaras

Post by Dale
that excessively long qt package

Off-topic, but just in case you mean qtwebengine, I was able to get
rid of it by putting "-webengine" in my USE flags.

I got rid of it by switching to a flatpak version of the singular
desktop application that required it on my system.

Normally I'll always choose a native package but qtwebengine builds for
a program that I run a couple of times a week skews the reward/effort
ratio.

[David Rosenbaum]

Thank u

David

Post by Dale
Howdy,
I was wondering. Is there a way to highlight certain packages that are
about to be upgraded? Example, I like to know when some larger packages
like Firefox, LOo, that excessively long qt package and a couple others
are going to be upgraded. Some that are listed in the world file show
up in a darker green and are easier to see however, some are not. They
are dependencies of another package but I'd like to have them stick out
in the list of packages to be upgraded. I don't recall ever seeing
anyone mention this as a feature of emerge or heard of a way to
configure such a thing either. That said, it could be possible and just
not well known.
I'd like to be able to have those packages show up as red or something
like that. If it is possible.
Thoughts? Ever heard of such a thing?
Dale
:-) :-)