* [gentoo-amd64] Re: package.provided and virtual/mysql problem
@ 2010-01-29 9:20 99% ` Duncan
0 siblings, 0 replies; 1+ results
From: Duncan @ 2010-01-29 9:20 UTC (permalink / raw
To: gentoo-amd64
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
^ permalink raw reply [relevance 99%]
Results 1-1 of 1 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2010-01-29 3:38 [gentoo-amd64] package.provided and virtual/mysql problem Juan Fco. Giordana
2010-01-29 9:20 99% ` [gentoo-amd64] " Duncan
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox