[gentoo-user] where are the version numbers of a profile stored?

[gentoo-user] where are the version numbers of a profile stored?

[n952162]

When I do an emerge --sync, various ebuilds are loaded onto my system,
co-existing with other ebuilds, possibly from the same package.  What
determines which package version is to be used?

I assumed this was specified by the profile (e.g. 17.1), but I can't
find any version numbers in /etc/portage/make.profile/

Re: [gentoo-user] where are the version numbers of a profile stored?

[n952162]

On 2020-06-07 19:31, n952162 wrote:
> When I do an emerge --sync, various ebuilds are loaded onto my system,
> co-existing with other ebuilds, possibly from the same package. What
> determines which package version is to be used?
>
> I assumed this was specified by the profile (e.g. 17.1), but I can't
> find any version numbers in /etc/portage/make.profile/
>
>

I just tried using a wildcard with this equery module:

  (l)ist                  list package matching PKG

and got basically what I needed

     $ equery list \* | grep readline
     sys-libs/readline-7.0_p5-r1

Although, I'm still curious where that information is stored.

Re: [gentoo-user] where are the version numbers of a profile stored?

[Rich Freeman]

On Sun, Jun 7, 2020 at 1:31 PM n952162 <n952162@web.de> wrote:
>
> When I do an emerge --sync, various ebuilds are loaded onto my system,
> co-existing with other ebuilds, possibly from the same package.  What
> determines which package version is to be used?
>
> I assumed this was specified by the profile (e.g. 17.1), but I can't
> find any version numbers in /etc/portage/make.profile/
>

The process is exclusionary, not inclusionary, for the most part,
which is why the profiles tend to be simple and not list a lot of
packages or versions.

Portage installs the highest version of a package which is not blocked
for some reason, unless you explicitly tell it to install a particular
version of a package (which still will only install if not blocked for
some reason).

So, if you type:
emerge '=app-shells/bash-5.0_p11'

Then portage will install that version of bash if it is not blocked
for some reason.

If you type:
emerge app-shells/bash

Then portage will install the latest version of bash that is not
blocked for some reason.

The same applies to dependencies pulled in by packages - if a
particular version is pulled in then that version will be installed if
possible.  If a dependency is mentioned then the latest allowable
version will be installed.  The dependency can also include version
restrictions in which case the latest version allowed with the
additional restrictions will be installed.  I'll leave out USE
dependencies, which impose more rules.

So, at that point the only thing that matters is the various
mechanisms that block package versions from installing: masks and
keywords.

Keywords: A package version can only be installed if it contains an
accepted keyword.  Keywords can be accepted by your profile or by your
make.conf.  Eg, ~amd64 or amd64.  If the package does not declare any
keyword that you are accepting, then it will not be used.  This is the
main mechanism used to determine what version you will get.  Packages
are keyworded based on whether they work (~arch) or are considered
stable (arch) on a particular architecture.

Masks:  A package version cannot be installed if it is masked.  This
can be set in /etc/portage/package.mask, or by a profile.  Masks are
used for a lot of reasons - sometimes to stage package versions for
broader testing before being released, and sometimes because they
don't work well in a particular profile, and often for security
concerns or as a prelude to removal.

If you post a specific example I can explain what version will be
installed, assuming you don't have any dependencies with version
restrictions, and you will need to tell me what your ACCEPT_KEYWORDS
and profile are set to.

-- 
Rich

Re: [gentoo-user] where are the version numbers of a profile stored?

[n952162]

On 2020-06-07 20:22, Rich Freeman wrote:
> On Sun, Jun 7, 2020 at 1:31 PM n952162 <n952162@web.de> wrote:
>> When I do an emerge --sync, various ebuilds are loaded onto my system,
>> co-existing with other ebuilds, possibly from the same package.  What
>> determines which package version is to be used?
>>
>> I assumed this was specified by the profile (e.g. 17.1), but I can't
>> find any version numbers in /etc/portage/make.profile/
>>
> The process is exclusionary, not inclusionary, for the most part,
> which is why the profiles tend to be simple and not list a lot of
> packages or versions.


Okay, that's understandable.


> Keywords: A package version can only be installed if it contains an
> accepted keyword.  Keywords can be accepted by your profile or by your
> make.conf.  Eg, ~amd64 or amd64.  If the package does not declare any
> keyword that you are accepting, then it will not be used.  This is the
> main mechanism used to determine what version you will get.  Packages
> are keyworded based on whether they work (~arch) or are considered
> stable (arch) on a particular architecture.


Regarding ~amd64 vs. amd64 - these are both just keywords, reflecting
only  a qualitative difference, not a special syntax understood by
ebuild/emerge?

> If you post a specific example I can explain what version will be
> installed, assuming you don't have any dependencies with version
> restrictions, and you will need to tell me what your ACCEPT_KEYWORDS
> and profile are set to.
>

Please see my following posting on my other, concurrent thread.

Re: [gentoo-user] where are the version numbers of a profile stored?

[Rich Freeman]

On Sun, Jun 7, 2020 at 2:46 PM n952162 <n952162@web.de> wrote:
>
>
> Regarding ~amd64 vs. amd64 - these are both just keywords, reflecting
> only  a qualitative difference, not a special syntax understood by
> ebuild/emerge?
>

Honestly, I'm not actually sure whether portage has any logic that
gives these meaning.  If you did a sed on the entire tree and replaced
"~amd64" with "apple" and "amd64" with "pear" I suspect that wouldn't
break anything, but I'm not sure if there is logic that gives ~arch
some special treatment compared to arch.

In practice amd64 means that a package is stable on amd64, and ~amd64
means that a package is flagged as being of "testing" quality on
amd64.  The threshold for the latter is that it builds and doesn't
break or have serious problems.  The threshold for stability is that
it typically has been around for 30 days and is suitable for stable
users (I won't go into the details).

-- 
Rich