1 |
On 09/03/2014 17:34, Walter Dnes wrote: |
2 |
> I build uzbl (a webkit-based browser) from the git version, but I pull |
3 |
> in the dependancies, including webkit-gtk, via portage. A bit of |
4 |
> explanation first. uzbl has 2 options... |
5 |
> 1) webkit-gtk-1.x combined with gtk+-2.x |
6 |
> 2) webkit-gtk-2.x combined with gtk+-3.x |
7 |
> |
8 |
> To view Youtube and other Flash sites, you need Flash (dohhh). Flash |
9 |
> is a gtk2 app, and does not work with gtk3. So I need option 1) above, |
10 |
> which I force via a "local.mk" file. I have it working on machine A, so |
11 |
> I go to machine B. On machine B, the uzbl git build swears up and down |
12 |
> that it can't find webkit-gtk-1.x, and fails. I compare the 2 machines. |
13 |
> On machine A, I apparently emerged net-libs/webkit-gtk-1.8.3-r201:2 |
14 |
> whilst I had emerged net-libs/webkit-gtk-1.8.3-r300:3 on machine B. So |
15 |
> I switched machine B over to net-libs/webkit-gtk-1.8.3-r201:2 and uzbl |
16 |
> built fine, and works. |
17 |
> |
18 |
> Now for the question... I had always thought that it was the major |
19 |
> version number of the ebuild that determined the major version number of |
20 |
> the package, not a weird extension attached to the end of the version |
21 |
> number of the ebuild. What gives? |
22 |
> |
23 |
|
24 |
The major version of the package has not changed, for both it is still |
25 |
1.8.3. That is determined by upstream and the ebuild maintainer should |
26 |
not change that. |
27 |
|
28 |
There is some difference in built binaries between the -r201 and -r300 |
29 |
*gentoo revisions*, again this is determined by upstream and how the |
30 |
package builds. Apparently, USE flags were not appropriate as the |
31 |
maintainer chose not to go that route. |
32 |
|
33 |
From a purely "look at the version and it should make total sense" |
34 |
perspective, the versioning is far from ideal. From a "that's what |
35 |
upstream does, what else do you expect me to do?" perspective, it's the |
36 |
best solution. |
37 |
|
38 |
There are far worse ways to go about it, such as two totally different |
39 |
packages plus a virtual, all for no good reason |
40 |
|
41 |
|
42 |
|
43 |
-- |
44 |
Alan McKinnon |
45 |
alan.mckinnon@×××××.com |