[gentoo-amd64] Re: package.provided and virtual/mysql problem

[Duncan]

Juan Fco. Giordana posted on Fri, 29 Jan 2010 03:38:06 +0000 as excerpted:

> I mantain my own copy of dev-db/mysql (5.1.42) so I have the following
> information in my package.provided and virtuals files.
>
> ~ $ cat /etc/portage/profile/package.provided
> mail-mta/netqmail-1.06 dev-db/mysql-5.0.84-r1
>
> ~ $ cat /etc/portage/profile/virtuals
> virtual/mta mail-mta/netqmail
> virtual/mysql dev-db/mysql
>
> This worked ok so far until a few days ago. After syncing the tree
> 'emerge -avuDN world' wants to add 'virtual-mysql-5.0' overriding (I
> think) the settings I've specified above.
>
> This is happening on two Gentoo servers I mantain and I have the same
> problem on my desktop computer, which runs Funtoo, but with Funtoo the
> problem appeared a few months ago. I don't recall exactly how long.
>
> I've been searching the net for a few days and trying to find some
> orientation on IRC but so far I'm still clueless.

There are two types of virtuals, the old style, entirely virtual (no 
ebuild), and the new style, which consists of a "meta" ebuild that doesn't 
really install anything itself, but has various dependencies.

The profile/virtuals files (both in /etc/portage and in the cascading tree 
profiles themselves, FWIW, /etc/portage/profile is simply added on top of 
whatever tree profile you have, overruling it where there's a conflict 
just as the tree profile children overrule the parents where there's a 
conflict) simply tell portage which of the dependencies to fill the 
virtual with by default, which was all that was needed with old-style 
virtuals.  What they do NOT do, however, is act as package.provided for 
the new style virtuals that are real ebuilds, but with dependencies only, 
nothing to install of their own.

I'm no gentoo/mysql guru, but based on the above, what I'm guessing 
happened is that something you have installed that depends on mysql, was 
converted to depend on the virtual (or maybe it depends on a specific 
mysql slot (tho mysql doesn't seem to be slotted so that wouldn't be the 
case here), or has some other similarly not plain-jane dependency that the 
virtual you setup no longer provides), thus pulling in the real virtual 
ebuild.  If I'm correct, you should be able to do an equery depends 
virtual/mysql, and see what comes up.  (FWIW, I don't have mysql installed 
here, but that equery turns up three packages depending on the virtual, 
all three with that dependency controlled by the mysql USE flag.)  If you 
check that changelog, you may well see when the change was made -- note 
that if you're on stable, it may well have been actually made some time 
ago, but only recently stabilized.  That's what may have changed.  An 
emerge --tree (with other switches like --pretend and --verbose) can also 
be useful in obtaining the same information, in a different way.

> Can this be considered a normal operation?

Yes, I believe so.

> If so, what should I do with the entries in the virtuals file.

The virtuals file... well, let me just quote the portage (5) manpage:

>> This controls what packages will provide a virtual by default.
>> For example,  if  a package  needs to send e-mail, it will need
>> virtual/mta.  In the absence of a package that provides
>> virtual/mta (like qmail, sendmail, postfix, etc...), portage
>> will look  here to see what package to use.  In this case,
>> Gentoo uses net-mail/ssmtp as the default (as defined in
>> the virtuals file) because it's the package that does
>> the very bare minimum to send e-mail.

So all the virtuals file does is tell portage what the DEFAULT provider 
for that virtual should be.  Once ANY provider satisfies the virtual, the 
virtuals file no longer matters, as portage uses whatever's installed to 
fill the dependency, ignoring what the virtuals file says the default 
should be.

Thus, in practice, the virtuals file, at least the one in
/etc/portage/profile/, doesn't really have a /lot/ of effect for most 
people, because by the time they figure out that they want to change the 
default provider, they usually have something installed that fills the 
dependency anyway.  (Of course, for folks using the same config for a 
whole slew of machines, including installing new machines, it would, since 
then it would determine the default, but that's not the "most people" I 
was talking about. =:^)

It's thus likely that you can remove your /etc/portage/profile/virtuals 
file entirely, because all it sets is the defaults, and chances are you 
already have some package filling the dependency, default or not, and you 
thus probably don't need the virtuals file at all.

> Is it safe to allow virtual/mysql-5.0 to be installed in this case?

It should be safe, yes, as long as it's ONLY the virtual/mysql ebuild 
that's trying to install, not the "real" ebuild.  Remember, virtual 
packages don't install anything themselves, all they do is ensure one of 
the several dependencies filling the virtual is installed.  Since you have 
one of them in package.provided, you /should/ be fine.

But do note the general caveat that certain dependency version constraints 
may at some point pull in a different version than you have in 
package.provided.  That's one of the reasons for the --pretend and --ask 
options, to allow you to check for such possibilities, and check into 
things a bit further if something unexpected is occurring.  (Of course, I 
have a feeling you know that already and rely on it, or this thread 
wouldn't be occurring as you'd have never known it happened, if you 
weren't already checking such things! =:^)  Just a word of caution.  Don't 
expect package.provided to fill requirements for versions that aren't 
provided, is all.  But you probably already knew that.

In theory, you could package.provided the virtual too.  But there's no 
real reason to do so, since it /is/ a virtual, only installing an "empty" 
package, which is only used to bring in the dependencies, the one of which 
we actually care about being in your package.provided, so no worries, it 
would appear.  I'd just let the virtual install, as I don't think 
package.provided was setup with virtuals in mind, and you /might/ get 
strange and exotic bugs if you package.provide a virtual.  Of course if 
it's not a production box and you /like/ tracing bugs, go right ahead.  
Who knows what challenges you might find awaiting you! =;^)  (Actually, in 
theory you shouldn't find any such bugs, because the new style virtuals 
/are/ simply an empty ebuild, only pulling in dependencies, and that's the 
same functionality portage uses all the time.  However, as we all know, 
theory and reality don't always align so well!  Personally, I'd not wish 
to test fate, unless of course that's the sort of thing you find 
pleasurably challenging. =;^)

> Can this be considered a bug?

At this time, I'd not consider it so.  If it's trying to install a non-
virtual package, /then/ it might be, or it might simply be getting a range 
dependency that your package.provided doesn't fill.  But that doesn't 
appear to be the case from what you've written, so it wouldn't appear to 
be a bug.

Hope that clears things up for you! =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman