Add a USE flag for Plasma's Welcome Center?

[ruby_R53]

Really, the only package that depends on it is plasma-meta itself. If the user is already familiar with KDE Plasma, it becomes useless.

If I wanna remove it, that means I'll have to uninstall plasma-meta as well and then I'll have to manually select all the other packages I want to keep so that they don't get removed in a future --depclean.

I know I could emerge plasma-desktop or kdecore-meta instead but I don't wanna bother manually installing all the other packages I need. It would be a lot more efficient if plasma-meta had a USE flag for installing the Welcome Center instead.

[rab0171610]

I have the menu entry in the app menu set to hidden. If you don't want to do all the things you mentioned in your post to avoid it, then I'd suggest you do the same and then forget about it. The other option is to create an entry for it in package.provided. It is generally recommended to avoid that option unless you know what you are doing.

[ruby_R53]

i see, guess i can use the package.provided approach for now

[rab0171610]

I have one entry for package.provided. My general suggestion is to keep the entries limited to non-existent. Make sure you don't forget about them in case there are issues or unexpected behavior. Comment them out and see if that fixes the problem before filing bug reports or asking for help. In this case, I don't see that it would do much harm as the program is very basic, independent and non-essential. However you have to provide a package version number which means you would have to update the entry indefinitely. When taking that into consideration, the best option is just to hide the menu entry with kmenuedit and forget about it. It really doesn't take up space and is non-intrusive.

[ruby_R53]

yeah that makes sense, plasma doesn't get updates that often so it's not a big deal

[rab0171610]

Hypothetically, it should work indefinitely with any package version, even one from years back or an invalid version number that never existed. Possibly even <category/packagename>-0 or <category/packagename>-1.

[ruby_R53]

interesting, i wonder why you can't just use a * for all versions instead

[Hu]

package.provided is for assuring Portage that the identified package is present, and that Portage therefore does not need to install it. You cannot pre-install all possible versions of a package, so you cannot assure Portage that all versions are present.

[ruby_R53]

ohh that makes sense now x)

[NeglectedRudderPug]

Another method I used; which is not supported or considered correct:
Apply the --ask flag with emerge and see what packages the meta package wants to pull in after you have applied the use flags.

Go through the list (and compare to packages.gentoo.org if unsure what it is/does.) to see what you do/do not want.

Add the ones you want to your world file, run emerge and let it install them. You might need to set other use flags depending on your case. (I know I had to.)

It's not the correct, advisable or sensible way to do things, but it's a useful cheat.

[rab0171610]

NeglectedRudderPug,
For the future, consider using custom sets instead of adding packages to your world file.
https://wiki.gentoo.org/wiki/Package_sets#Custom_sets
https://wiki.gentoo.org/wiki//etc/portage/sets
kde-plasma/plasma-meta use flags are rather comprehensive so it is much less time consuming to tailor the Plasma installation to your liking with the given use flags instead. Categories and names of packages can sometimes be changed, renamed or moved in portage. Those changes need to be tracked and updated to keep the set maintained. Also, when new major versions of application suites come out, like with the change to KDE 5 to KDE 6, many of the upstream packages can be absorbed into one another, made obsolete and new ones created. This is less of a challenge when just relying on use flags to tailor the installation.

[NeglectedRudderPug]

[ruby_R53]

[NeglectedRudderPug]