| 1 |
On Fri, May 29, 2015 at 10:11 PM, Andrew Savchenko <bircoph@g.o> wrote: |
| 2 |
> On Fri, 29 May 2015 18:48:55 -0700 walt wrote: |
| 3 |
>> |
| 4 |
>> The libreoffice-bin package wanted to drag in dozens of other non-binary |
| 5 |
>> gentoo packages before it would install itself, and even caused a blocker |
| 6 |
>> between two different versions of poppler. (I said "no" because I thought |
| 7 |
>> the blocker would make the entire experiment fail in the end.) |
| 8 |
> |
| 9 |
> It requires many other packages because it was compiled with |
| 10 |
> specific versions of that packages. Of course that other packages |
| 11 |
> will be source ebuilds mostly. |
| 12 |
> |
| 13 |
> You have blockers because your current system have different |
| 14 |
> versions of some of that packages. These issues are usually solved |
| 15 |
> either via slot installs or update of your currently installed |
| 16 |
> system. Sometimes emerge -DNu @world may be needed. |
| 17 |
> |
| 18 |
|
| 19 |
Just a bit more explanation... |
| 20 |
|
| 21 |
Binary distros, like Debian, typically solve this problem by using |
| 22 |
releases. In a release most packages have fixed versions, especially |
| 23 |
those which have many reverse dependencies, like core libraries. When |
| 24 |
Debian 9 is being prepared for release, somebody will decide that it |
| 25 |
will use poppler version 0.35 or whatever is in vogue at the time, and |
| 26 |
so on. Then all the maintainers will build all the packages that use |
| 27 |
it against poppler-0.35. This prevents the blocker situation that |
| 28 |
you're witnessing. If there is a later security patch, any fixes will |
| 29 |
be backported as needed so that they can stay with poppler-0.35 which |
| 30 |
prevents them from having to update dozens or hundreds of other |
| 31 |
packages in some kind of coordinated mini-release. Eventually a new |
| 32 |
release comes along, and they update all of their packages in lockstep |
| 33 |
to a new set of versions, so that they reach a new consistent |
| 34 |
depgraph. Of course, they can use the equivalent of slots as well, so |
| 35 |
for some libraries they may support more than one specific version, |
| 36 |
but it is still coordinated in this manner. |
| 37 |
|
| 38 |
With Gentoo we're spoiled by the ability to generally be able to |
| 39 |
install arbitrary pairings of package versions, since we build |
| 40 |
everything from source and emerge will link everything against |
| 41 |
whatever we're using. When we do change a key dependency, then a |
| 42 |
combination of slot-operator-deps, preserved-rebuild, and |
| 43 |
revdep-rebuild will rebuild everything that breaks. Of course, we're |
| 44 |
still limited by API-compatibility and feature use, which puts some |
| 45 |
constraints on what we can install. We're even more limited when |
| 46 |
braindead upstreams don't properly use SONAMEs and such, which creates |
| 47 |
blockers that can't be resolved using slots. However, in general we |
| 48 |
get a lot of flexibility, which lets us keep most packages closer to |
| 49 |
upstream and we don't have to packport fixes to poppler-0.35 for 3 |
| 50 |
years since we can just use poppler-0.36 instead, and so on. |
| 51 |
|
| 52 |
However, the moment you start installing packages that use precompiled |
| 53 |
dynamic binaries we become just like Debian, except we DON'T use |
| 54 |
releases and thus we don't guarantee tree-wide compatibility with a |
| 55 |
very specific version of every library. So, once you start installing |
| 56 |
these packages you're much more likely to run into blockers and other |
| 57 |
issues, especially if you have a fair number of them. They exist for |
| 58 |
convenience, but you'll never get the full "Gentoo experience" using |
| 59 |
them, and if you're really looking to use a lot of standardized binary |
| 60 |
packages for everything, well, you're probably better-off with a |
| 61 |
distro designed with that in mind (ie, basically everybody else). |
| 62 |
|
| 63 |
-- |
| 64 |
Rich |
Archives