Does package.provided discriminate against virtual packages?

[dantrell]

Case in point:

Code: Select all

# emerge --pretend strongswan

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

Calculating dependencies... done!
[ebuild  N     ] virtual/logger-0-r1 
[ebuild  N     ] sys-kernel/vanilla-sources-5.5.7  USE="-build -symlink" 
[ebuild  N     ] virtual/linux-sources-3-r4  USE="-firmware" 
[ebuild   R    ] net-vpn/strongswan-5.8.2 

Now given:

Code: Select all

sys-kernel/vanilla-sources-9999-r9999
virtual/linux-sources-3-r3
#virtual/linux-sources-3-r4
virtual/linux-sources-3-r5
virtual/linux-sources-9999-r9999

We get:

Code: Select all

# emerge --pretend strongswan

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

Calculating dependencies... done!
[ebuild  N     ] virtual/linux-sources-3-r4  USE="-firmware" 
[ebuild  N     ] virtual/logger-0-r1 
[ebuild   R    ] net-vpn/strongswan-5.8.2

The virtual is ignored unless we specify the exact version (by uncommenting that one line):

Code: Select all

# emerge --pretend strongswan

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

Calculating dependencies... done!
[ebuild  N     ] virtual/logger-0-r1 
[ebuild   R    ] net-vpn/strongswan-5.8.2 

What gives?

[Anon-E-moose]

Yes, you have to use the version number

https://wiki.gentoo.org/wiki//etc/porta ... e.provided

[dantrell]

just use "virtual/linux-sources" without the version and rev number

As per the package.provided format rules a version must be included or emerge will throw a:

Code: Select all

Invalid package name in package.provided

[Anon-E-moose]

Sorry, after I checked my own and realized that my original post was wrong, I changed, it.

But it's not because it's a virtual package, it's just the way they implemented package.provided.

[dantrell]

But it's not because it's a virtual package, it's just the way they implemented package.provided.

I think you are misunderstanding my question.

I understand you have to use a version number but why do virtual package require an exact version match down to the revision number?

Notice, sys-kernel/vanilla-sources does not require an exact version match.

[Anon-E-moose]

Why they did it that way for package.provided, I don't know, perhaps the whole package.provided was an afterthought.

I usually resort to package.mask and/or dummy ebuilds and use provided as little as possible.

Notice, sys-kernel/vanilla-sources does not require an exact version match.

It does the way you're using it, vanilla-sources-9999-99 is the highest level of vanilla-sources there can be so everything less than it is satisfied in this case.

I'm curious, what does emerge show using virtual/linux-sources-4 instead of all the -3-r* lines

[dantrell]

I usually resort to package.mask and/or dummy ebuilds and use provided as little as possible.

There are a number of workarounds here but none as "maintenance-free" as package.provided accepting non-exact versions.

It does the way you're using it, vanilla-sources-9999-99 is the highest level of vanilla-sources there can be so everything less than it is satisfied in this case.

Exactly.

I purposely want an almost zero percentage chance that I'm ever asked about the package.

Since I apparently haven't come across needing to list a virtual package in package.provided until now, I didn't realize that non-exact versions doesn't apply to virtual packages.

I'm curious, what does emerge show using virtual/linux-sources-4 instead of all the -3-r* lines

My example was simplified but nothing but the exact version and revision works for virtual packages (e.g. using 0, 2, 4 or say 25 will not work).

Why they did it that way for package.provided, [...]

I'd like to say it's a bug but who knows?

If there weren't any "maintenance-free" workarounds I probably wouldn't even have inquired.

I'll probably end up writing a snippet to auto-populate package.provided.

[Genone]

package.provided was originally intended for a different purpose: To describe system packages available in the host system of a prefix installation. And obviously that needs proper versions to function as you can't do a version comparison against an unversioned package (atom vs. CPV for those familiar with internals).

As for why virtuals are apparently behaving differently than real packages, I'd assume that has something to do with old-style (non-ebuild) virtuals compatibility/transistioning.

[dantrell]

package.provided was originally intended for a different purpose: To describe system packages available in the host system of a prefix installation. And obviously that needs proper versions to function as you can't do a version comparison against an unversioned package (atom vs. CPV for those familiar with internals).

Always interesting to hear how things were originally intended (especially in comparison to what they eventually became).

As for why virtuals are apparently behaving differently than real packages, I'd assume that has something to do with old-style (non-ebuild) virtuals compatibility/transistioning.

I just wanted to make sure there was a reason for the behaviour and now that I'm pretty sure there is I'll definitely be writing a snippet to auto-populate package.provided and calling it day.

Thanks for chiming in.

[krinn]

As for why virtuals are apparently behaving differently than real packages, I'd assume that has something to do with old-style (non-ebuild) virtuals compatibility/transistioning.

I just wanted to make sure there was a reason for the behaviour and now that I'm pretty sure there is I'll definitely be writing a snippet to auto-populate package.provided and calling it day.

Thanks for chiming in.

Actually, it doesn't make sense ; the chewbacca defense! , virtual ebuilds have an EAPI tag too, so base on EAPI old virtual could behave like before (or when lack of EAPI entry), and newer EAPI ones should behave like any packages, allowing for compatibility while allowing newer (better) behaviour of versionless package.provided

[dantrell]

Actually, it doesn't make sense ; the chewbacca defense! , virtual ebuilds have an EAPI tag too, so base on EAPI old virtual could behave like before (or when lack of EAPI entry), and newer EAPI ones should behave like any packages, allowing for compatibility while allowing newer (better) behaviour of versionless package.provided

Well, I agree it doesn't make sense now (hence the thread) but it (probably) made sense at the time it was conceptualized.

As for the Chewbacca Defense, all I'll say is that after approximately two decades of Linux, when it comes to "issues" and upstream developers and their respective bureaucratic processes, I have no interest in participating. I just deal with the issue on my end and move on (case in point, the aforementioned snippet was written, tested and implemented).

But don't let that stop you (or anyone else) if you would argue that a bug should be filed and are willing to do so.