Gentoo Archives: gentoo-amd64

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-amd64@l.g.o
Subject: [gentoo-amd64] Re: package.provided and virtual/mysql problem
Date: Fri, 29 Jan 2010 09:21:54
In Reply to: [gentoo-amd64] package.provided and virtual/mysql problem by "Juan Fco. Giordana"
1 Juan Fco. Giordana posted on Fri, 29 Jan 2010 03:38:06 +0000 as excerpted:
3 > I mantain my own copy of dev-db/mysql (5.1.42) so I have the following
4 > information in my package.provided and virtuals files.
5 >
6 > ~ $ cat /etc/portage/profile/package.provided
7 > mail-mta/netqmail-1.06 dev-db/mysql-5.0.84-r1
8 >
9 > ~ $ cat /etc/portage/profile/virtuals
10 > virtual/mta mail-mta/netqmail
11 > virtual/mysql dev-db/mysql
12 >
13 > This worked ok so far until a few days ago. After syncing the tree
14 > 'emerge -avuDN world' wants to add 'virtual-mysql-5.0' overriding (I
15 > think) the settings I've specified above.
16 >
17 > This is happening on two Gentoo servers I mantain and I have the same
18 > problem on my desktop computer, which runs Funtoo, but with Funtoo the
19 > problem appeared a few months ago. I don't recall exactly how long.
20 >
21 > I've been searching the net for a few days and trying to find some
22 > orientation on IRC but so far I'm still clueless.
24 There are two types of virtuals, the old style, entirely virtual (no
25 ebuild), and the new style, which consists of a "meta" ebuild that doesn't
26 really install anything itself, but has various dependencies.
28 The profile/virtuals files (both in /etc/portage and in the cascading tree
29 profiles themselves, FWIW, /etc/portage/profile is simply added on top of
30 whatever tree profile you have, overruling it where there's a conflict
31 just as the tree profile children overrule the parents where there's a
32 conflict) simply tell portage which of the dependencies to fill the
33 virtual with by default, which was all that was needed with old-style
34 virtuals. What they do NOT do, however, is act as package.provided for
35 the new style virtuals that are real ebuilds, but with dependencies only,
36 nothing to install of their own.
38 I'm no gentoo/mysql guru, but based on the above, what I'm guessing
39 happened is that something you have installed that depends on mysql, was
40 converted to depend on the virtual (or maybe it depends on a specific
41 mysql slot (tho mysql doesn't seem to be slotted so that wouldn't be the
42 case here), or has some other similarly not plain-jane dependency that the
43 virtual you setup no longer provides), thus pulling in the real virtual
44 ebuild. If I'm correct, you should be able to do an equery depends
45 virtual/mysql, and see what comes up. (FWIW, I don't have mysql installed
46 here, but that equery turns up three packages depending on the virtual,
47 all three with that dependency controlled by the mysql USE flag.) If you
48 check that changelog, you may well see when the change was made -- note
49 that if you're on stable, it may well have been actually made some time
50 ago, but only recently stabilized. That's what may have changed. An
51 emerge --tree (with other switches like --pretend and --verbose) can also
52 be useful in obtaining the same information, in a different way.
54 > Can this be considered a normal operation?
56 Yes, I believe so.
58 > If so, what should I do with the entries in the virtuals file.
60 The virtuals file... well, let me just quote the portage (5) manpage:
62 >> This controls what packages will provide a virtual by default.
63 >> For example, if a package needs to send e-mail, it will need
64 >> virtual/mta. In the absence of a package that provides
65 >> virtual/mta (like qmail, sendmail, postfix, etc...), portage
66 >> will look here to see what package to use. In this case,
67 >> Gentoo uses net-mail/ssmtp as the default (as defined in
68 >> the virtuals file) because it's the package that does
69 >> the very bare minimum to send e-mail.
71 So all the virtuals file does is tell portage what the DEFAULT provider
72 for that virtual should be. Once ANY provider satisfies the virtual, the
73 virtuals file no longer matters, as portage uses whatever's installed to
74 fill the dependency, ignoring what the virtuals file says the default
75 should be.
77 Thus, in practice, the virtuals file, at least the one in
78 /etc/portage/profile/, doesn't really have a /lot/ of effect for most
79 people, because by the time they figure out that they want to change the
80 default provider, they usually have something installed that fills the
81 dependency anyway. (Of course, for folks using the same config for a
82 whole slew of machines, including installing new machines, it would, since
83 then it would determine the default, but that's not the "most people" I
84 was talking about. =:^)
86 It's thus likely that you can remove your /etc/portage/profile/virtuals
87 file entirely, because all it sets is the defaults, and chances are you
88 already have some package filling the dependency, default or not, and you
89 thus probably don't need the virtuals file at all.
91 > Is it safe to allow virtual/mysql-5.0 to be installed in this case?
93 It should be safe, yes, as long as it's ONLY the virtual/mysql ebuild
94 that's trying to install, not the "real" ebuild. Remember, virtual
95 packages don't install anything themselves, all they do is ensure one of
96 the several dependencies filling the virtual is installed. Since you have
97 one of them in package.provided, you /should/ be fine.
99 But do note the general caveat that certain dependency version constraints
100 may at some point pull in a different version than you have in
101 package.provided. That's one of the reasons for the --pretend and --ask
102 options, to allow you to check for such possibilities, and check into
103 things a bit further if something unexpected is occurring. (Of course, I
104 have a feeling you know that already and rely on it, or this thread
105 wouldn't be occurring as you'd have never known it happened, if you
106 weren't already checking such things! =:^) Just a word of caution. Don't
107 expect package.provided to fill requirements for versions that aren't
108 provided, is all. But you probably already knew that.
110 In theory, you could package.provided the virtual too. But there's no
111 real reason to do so, since it /is/ a virtual, only installing an "empty"
112 package, which is only used to bring in the dependencies, the one of which
113 we actually care about being in your package.provided, so no worries, it
114 would appear. I'd just let the virtual install, as I don't think
115 package.provided was setup with virtuals in mind, and you /might/ get
116 strange and exotic bugs if you package.provide a virtual. Of course if
117 it's not a production box and you /like/ tracing bugs, go right ahead.
118 Who knows what challenges you might find awaiting you! =;^) (Actually, in
119 theory you shouldn't find any such bugs, because the new style virtuals
120 /are/ simply an empty ebuild, only pulling in dependencies, and that's the
121 same functionality portage uses all the time. However, as we all know,
122 theory and reality don't always align so well! Personally, I'd not wish
123 to test fate, unless of course that's the sort of thing you find
124 pleasurably challenging. =;^)
126 > Can this be considered a bug?
128 At this time, I'd not consider it so. If it's trying to install a non-
129 virtual package, /then/ it might be, or it might simply be getting a range
130 dependency that your package.provided doesn't fill. But that doesn't
131 appear to be the case from what you've written, so it wouldn't appear to
132 be a bug.
134 Hope that clears things up for you! =:^)
136 --
137 Duncan - List replies preferred. No HTML msgs.
138 "Every nonfree program has a lord, a master --
139 and if you use the program, he is your master." Richard Stallman


Subject Author
Re: [gentoo-amd64] Re: package.provided and virtual/mysql problem "Juan Fco. Giordana" <juangiordana@×××××.com>