On 09/03/2014 17:34, Walter Dnes wrote: > I build uzbl (a webkit-based browser) from the git version, but I pull > in the dependancies, including webkit-gtk, via portage. A bit of > explanation first. uzbl has 2 options... > 1) webkit-gtk-1.x combined with gtk+-2.x > 2) webkit-gtk-2.x combined with gtk+-3.x > > To view Youtube and other Flash sites, you need Flash (dohhh). Flash > is a gtk2 app, and does not work with gtk3. So I need option 1) above, > which I force via a "local.mk" file. I have it working on machine A, so > I go to machine B. On machine B, the uzbl git build swears up and down > that it can't find webkit-gtk-1.x, and fails. I compare the 2 machines. > On machine A, I apparently emerged net-libs/webkit-gtk-1.8.3-r201:2 > whilst I had emerged net-libs/webkit-gtk-1.8.3-r300:3 on machine B. So > I switched machine B over to net-libs/webkit-gtk-1.8.3-r201:2 and uzbl > built fine, and works. > > Now for the question... I had always thought that it was the major > version number of the ebuild that determined the major version number of > the package, not a weird extension attached to the end of the version > number of the ebuild. What gives? >
The major version of the package has not changed, for both it is still 1.8.3. That is determined by upstream and the ebuild maintainer should not change that. There is some difference in built binaries between the -r201 and -r300 *gentoo revisions*, again this is determined by upstream and how the package builds. Apparently, USE flags were not appropriate as the maintainer chose not to go that route. >From a purely "look at the version and it should make total sense" perspective, the versioning is far from ideal. From a "that's what upstream does, what else do you expect me to do?" perspective, it's the best solution. There are far worse ways to go about it, such as two totally different packages plus a virtual, all for no good reason -- Alan McKinnon [email protected]
