[SOLVED] What packages are/will-be installed by a profile

[z4]

There is sort of a way to tell what packages a given profile will emerge. I merely run

Code: Select all

emerge --ask --update --deep --newuse @world

after selecting a profile inside chroot on a freshly-untarred stage3 (after the usual preliminaries...).

But once a system is installed, how could I tell what packages were pulled in by the profile?
There are some references to the @profile set on the portage man-page, but

Code: Select all

$ equery l @profile
!!! No installed packages matching '@profile'

produces no joy. Did I bring this on myself, or is this more wide-spread? I'm still using

Code: Select all

$ eselect profile show
Current /etc/portage/make.profile symlink:
  default/linux/amd64/17.1/desktop

as my profile. Did profiles stop tracking their packages in general?

[fturco]

@profile does not exist by default as a set of packages. You probably need the @system set.

After setting your favorite profile with eselect, you can try with:

Code: Select all

emerge -pv @system

Edit: I was wrong. It seems the @profile set actually exists according to emerge --list-sets. Anyway it seems to be empty (at least on my system).

[NeddySeagoon]

Code: Select all

emerge -pv @world 

might be better.
It depends what is in world already.

[GDH-gentoo]

Code: Select all

$ equery l @profile
!!! No installed packages matching '@profile'

Probably because currently, for profile default/linux/amd64/17.1/desktop, the profile set contains no packages.

Code: Select all

$ eselect profile show
Current /etc/portage/make.profile symlink:
  default/linux/amd64/17.1/desktop

$ emerge -pv @profile

These are the packages that would be merged, in order:

Calculating dependencies... done!

Total: 0 packages, Size of downloads: 0 KiB

[z4]

Probably because currently, for profile default/linux/amd64/17.1/desktop, the profile set contains no packages.

Code: Select all

$ eselect profile show
Current /etc/portage/make.profile symlink:
  default/linux/amd64/17.1/desktop

$ emerge -pv @profile

These are the packages that would be merged, in order:

Calculating dependencies... done!

Total: 0 packages, Size of downloads: 0 KiB

That is a very awkwardly written assertion, as I happened to have logged the "emerge --update --deep --newuse @world" results, and I can assure you that 434 packages were pulled in on top of @system with nothing other than the "eselect ..." followed by the "emerge ..." Maybe you're not starting from a stage3 chroot. Regardless, the assertion that the 17.1/desktop profile does not have a single package in it cannot possibly be what you meant. It is precisely because I get the same results as you do that I posted this topic in the first place. Given that profiles are hierarchical, and pull in a chain of other profiles, there's got to be a single package somewhere (at a minimum) that gets emerged, no? And like I said, there are 434 that get pulled in, though I'm sure not all are leaves and many (probably most) are dependencies of the [at least one] leaf package(s).

Nevertheless, I was inspired to dig further, and found this in the layout.conf section of the portage man-page:

Code: Select all

                            profile-formats = [pms] [portage-1] [portage-2] [profile-bashrcs] [profile-set] [profile-
                            default-eapi] [build-id]
                                   Control functionality available to profiles in this repo such as which  files  may
                                   be  dirs,  or  the  syntax  available  in parent files.  Use "portage-2" if you're
                                   unsure.  The default is "portage-1-compat" mode which is meant  to  be  compatible
                                   with old profiles, but is not allowed to be opted into directly.  Setting profile-
                                   bashrcs will enable the per-profile bashrc mechanism package.bashrc. [b]Setting  pro-
                                   file-set  enables  support for using the profile packages file to add atoms to the
                                   @profile package set.[/b]  See the profile  packages  section  for  more  information.
                                   Setting profile-default-eapi enables support for the profile_eapi_when_unspecified
                                   attribute. Setting build-id allows dependency atoms in the  profile  to  refer  to
                                   specific  builds (see the binpkg-multi-instance FEATURES setting in make.conf(5)).
                                   A build-id atom is identical to a version-specific atom, except that  the  version
                                   is followed by a hyphen and an integer build-id.

So I added:

Code: Select all

diff --git a/metadata/layout.conf b/metadata/layout.conf
index 89383a671c4..c1e916d7343 100644
--- a/metadata/layout.conf
+++ b/metadata/layout.conf
@@ -50,3 +50,5 @@ thin-manifests = true
 # Sign Git commits, and NOT Manifests
 sign-commits = true
 sign-manifests = false
+
+profile-formats = profile-set

to my repo's metadata/layout.conf file. Note the

Setting profile-set enables support for using the profile packages file to add atoms to the @profile package set.

in the portage man-page. This seems to be the "magic" that the portage man-page is alluding to in order to have a "profile-set".

Sadly, there is no change. The @profile is still empty. But at least the man-page has exactly what I'm looking for, just doesn't work as documented. I'm wondering if there's some other setting somewhere that is overriding the layout.conf. I guess I'll keep digging...thanks again for the feedback.

[charles17]

z4,

You are going the hard way to learn about Gentoo, Portage and the profiles selection. Have you already looked into the packages files mentioned in the wiki?

The system packages are defined by the Gentoo profiles (through the packages files).

$ find /var/db/repos/gentoo/profiles -name packages

/var/db/repos/gentoo/profiles/base/packages
/var/db/repos/gentoo/profiles/prefix/mint/packages
/var/db/repos/gentoo/profiles/prefix/packages
/var/db/repos/gentoo/profiles/prefix/linux/packages
/var/db/repos/gentoo/profiles/prefix/linux/ppc64/packages
/var/db/repos/gentoo/profiles/prefix/darwin/packages
/var/db/repos/gentoo/profiles/prefix/darwin/macos/packages
/var/db/repos/gentoo/profiles/prefix/darwin/macos/10.10/packages
/var/db/repos/gentoo/profiles/prefix/darwin/macos/10.8/packages
/var/db/repos/gentoo/profiles/prefix/darwin/macos/10.6/packages
/var/db/repos/gentoo/profiles/prefix/darwin/macos/10.7/packages
/var/db/repos/gentoo/profiles/prefix/darwin/macos/10.11/packages
/var/db/repos/gentoo/profiles/prefix/darwin/macos/10.4/packages
/var/db/repos/gentoo/profiles/prefix/darwin/macos/10.9/packages
/var/db/repos/gentoo/profiles/prefix/darwin/macos/10.5/packages
/var/db/repos/gentoo/profiles/prefix/darwin/macos/10.5/ppc/packages
/var/db/repos/gentoo/profiles/prefix/sunos/packages
/var/db/repos/gentoo/profiles/prefix/sunos/solaris/5.11/packages
/var/db/repos/gentoo/profiles/prefix/aix/packages
/var/db/repos/gentoo/profiles/prefix/windows/cygwin/packages
/var/db/repos/gentoo/profiles/prefix/windows/winnt/packages
/var/db/repos/gentoo/profiles/arch/sparc/packages
/var/db/repos/gentoo/profiles/arch/riscv/packages
/var/db/repos/gentoo/profiles/arch/powerpc/packages
/var/db/repos/gentoo/profiles/arch/powerpc/ppc64/32ul/packages
/var/db/repos/gentoo/profiles/arch/s390/packages
/var/db/repos/gentoo/profiles/arch/hppa/packages
/var/db/repos/gentoo/profiles/embedded/packages
/var/db/repos/gentoo/profiles/default/linux/uclibc/packages
/var/db/repos/gentoo/profiles/default/linux/packages
/var/db/repos/gentoo/profiles/default/linux/musl/packages
/var/db/repos/gentoo/profiles/features/uclibc/packages
/var/db/repos/gentoo/profiles/features/prefix/packages
/var/db/repos/gentoo/profiles/features/prefix/standalone/packages
/var/db/repos/gentoo/profiles/features/prefix/rpath/packages
/var/db/repos/gentoo/profiles/features/musl/packages
/var/db/repos/gentoo/profiles/features/hardened/packages
/var/db/repos/gentoo/profiles/features/selinux/packages

Some of the packages pulled in when you run the emerge command come from these files. Others are pulled in by dependencies. Here, a good understanding of USE flags is needed.

[DONAHUE]

results may vary:

Code: Select all

# find /var/db/repos/gentoo/profiles -name packages
find: ‘/var/db/repos/gentoo/profiles’: No such file or directory

I have no /var/db/repos
I don't use eix, may be why

Code: Select all

find / -name packages

shows analogous structures at /root/gentoo/profiles and /usr/portage/profiles

[GDH-gentoo]

That is a very awkwardly written assertion, as I happened to have logged the "emerge --update --deep --newuse @world" results, and I can assure you that 434 packages were pulled in on top of @system with nothing other than the "eselect ..." followed by the "emerge ..."

Yeah. That would be the selected set (@selected) plus all dependencies of packages in that set. Such dependencias are neither in @selected, nor @profile, nor @system, and get removed by emerge --depclean when they are no longer needed.

Regardless, the assertion that the 17.1/desktop profile does not have a single package in it cannot possibly be what you meant.

Yes, that is what I meant. As the man page states, packages in @profile are those named in profiles' packages files that are not preceded by an asterisk (those that are, are members of the system set). You were shown the location of those files in you computer's copy of Gentoo's repository. Try to find packages without a preceding asterisk in them.

Note the

Setting profile-set enables support for using the profile packages file to add atoms to the @profile package set.

in the portage man-page. This seems to be the "magic" that the portage man-page is alluding to in order to have a "profile-set".

Sadly, there is no change. The @profile is still empty.

Well yeah, that only turns on for the associated repository the mechanism of adding packages without a preceding asterisk to @profile rather that ignoring them. If there aren't such packages, @profile will still be empty.

What I don't get is the fixation with the profile set. Generally speaking, profiles exist to ease USE flag management, based on your intended use of the installed system, and sometimes, to enforce a certain policy about their usage (flag masking and forcing), that's all. They don't define which packages are installed on your computer, other that system packages. You decide that. See the wiki article for the details.

The Package Management Specification also says about packages files, in section 5.2.6, "[...] its lines must take one of two forms: a package dependency specification prefixed by * denotes that it forms part of the system set. A package dependency specification on its own may also appear for legacy reasons, but should be ignored when calculating the system set". (Highlighting is mine).

[superjaded]

I can assure you that 434 packages were pulled in on top of @system with nothing other than the "eselect ..." followed by the "emerge ..." Maybe you're not starting from a stage3 chroot.

I don't think the person to whom you were responding was wrong. Seems to me you might be underestimating the effect USE flags can have.

Just out of curiosity, I set up a chroot on my main machine with a fresh stage3 tarball and then did the following after getting the actual chroot setup:

• emerge-webrsync / emerge --sync --quiet
• emerge -auDNv @world before changing profile
• eselect profile set 20 (default/linux/amd64/17.1/desktop)
• echo "dev-lang/python sqlite" > /etc/portage/package.use/polkit (get an error about that not existing)
• emerge -puDNv --tree @world

Which results in this monstrosity. You can get an idea of why a given packages was pulled in based where it shows up in the tree, such as app-text/poppler bringing in multiple qt libraries due to the qt5 USE flag being enabled. It's not the easiest output to follow due to the number of packages involved, but I'm not seeing anything that wasn't pulled in as a dependency of something else based on new USE flags.

In other news, my emerge -puDNv @world only pulled in 207 new packages (17 rebuilt, for a total of 228 packages), so I'm not sure where your 434 number is coming from.

[z4]

Thanks for the responses. I think I got it. I read all the man-page and #comment sections in the packages files and understand what they're supposed to do. In fact, I parsed all system atoms ("^*" and "^-*") from all packages files (find /usr/portage/ -name packages | xargs ...) and came up with the empty-set. So there is not a single profile that claims to own any of the packages it installs. That is a bit unexpected, but fair enough. So it really is the case that the profile just re-installs @system packages with changed USE flags, and the 434 packages that are pulled in by my 17.1/desktop profile are either the @system packages themselves or their [now additional due to USE flags change] dependencies. My "fixation" on profiles is merely one of seeking wisdom at a nauseatingly-detailed level, because I have a --deep desire to know where all packages came from. Thanks for putting up with my deep-dive and conquering of this learning curve. Just for the record, could someone please verify that my understand as described above is more-or-less accurate? Thanks...

[charles17]

... So there is not a single profile that claims to own any of the packages it installs. ...

Code: Select all

# Copyright 2004-2015 Gentoo Foundation.
# Distributed under the terms of the GNU General Public License v2

# This file extends the base packages file for the default profile that all
# architectures will enjoy.  Please note that default is what most architectures
# will have.  Some will have an selinux profile (see ${PORTDIR}/profiles/selinux).
# The idea is to only create a new family of profiles when absolutely necessary.

*sys-apps/busybox
*sys-apps/iproute2
*sys-apps/man-pages
*sys-apps/net-tools
*sys-apps/util-linux
/var/db/repos/gentoo/profiles/default/linux/packages lines 1-13/13 (END)

Not a profile requires them, but @system does dependent on the profile.

Code: Select all

$ emerge --pretend --verbose --depclean sys-apps/net-tools

Calculating dependencies... done!
  sys-apps/net-tools-1.60_p20180626073013 pulled in by:
    @system requires sys-apps/net-tools

>>> No packages selected for removal by depclean
Packages installed:   877
Packages in world:    98
Packages in system:   43
Required packages:    877
Number to remove:     0

[GDH-gentoo]

To elaborate on previous responses:

So there is not a single profile that claims to own any of the packages it installs. That is a bit unexpected, but fair enough.

Perhaps you had the wrong idea about what profiles do. They don't "install packages", although, as charles17 showed, they do influence, via package set definitions, what gets installed. Or, to be precise, what stays installed despite running emerge --depclean, because you initially get all packages in @system from the stage3 archive rather than by running emerge.

So it really is the case that the profile just re-installs @system packages with changed USE flags, and the 434 packages that are pulled in by my 17.1/desktop profile are either the @system packages themselves or their [now additional due to USE flags change] dependencies.

You are forgetting about the selected set. That is, the set of all packages you explicitly request with emerge (and without the --oneshot option). You can see the contents of @selected in several ways; if you have Gentoolkit, one of them is equery list @selected. So, to summarize, the set of installed packages is:

• Those in @system, which is defined by the profile.
• Those in @profile, which is also defined by the profile, but these days, it is empty.
• Those you explicitly install, i.e. @selected. Desktop environment metapackages, like gnome-base/gnome or kde-plasma/plasma-meta, fall in this category: you don't have a DE yet when you finish Gentoo installation, you have to ask for one if you want it.
• Dependencies of any package that is a member of @selected, @system and @profile. That is, dependencies of @world, which is defined as the union of those three sets. Like I said, dependencies installed automatically by emerge are not in any of those sets (and therefore, not in @world either). And, as it was also mentioned, USE flag settings, and therefore the currently selected profile, can also affect dependencies.

Those 434 packages you mention are those covered by the last two bullets.

My "fixation" on profiles is merely one of seeking wisdom at a nauseatingly-detailed level [...]

I have nice technical document for you

[z4]

Thanks everybody...I think we've beaten profiles to death now . Now how to change the Subject line to have a nice [SOLVED] in front of it...?

[superjaded]

Now how to change the Subject line to have a nice [SOLVED] in front of it...?

You should be able to do that by editing the subject line in your opening post in this thread.