| 1 |
On Sun, Jul 9, 2017 at 3:59 PM, Ста Деюс <sthu.deus@×××××××××××.org> wrote: |
| 2 |
> |
| 3 |
> Is it possible to compile/install a testing version of a package w/ its |
| 4 |
> dependencies on a stable OS installation? -- I mean, if a have stable |
| 5 |
> installation of whole the system, can i compile and install a testing |
| 6 |
> version of single package and the packages this single package depends |
| 7 |
> on? |
| 8 |
> |
| 9 |
|
| 10 |
Yes, for the most part. Obviously if whatever you want to install has |
| 11 |
a rats nest of unstable dependencies it can get messy. It isn't like |
| 12 |
you're going to be able to install one component of kde-6 on an |
| 13 |
otherwise kde-5 system, for example (when that comes along), and |
| 14 |
expect it to work. |
| 15 |
|
| 16 |
Typically you just stick whatever you're interested in |
| 17 |
/etc/portage/package.keywords. Then when you try to emerge it portage |
| 18 |
will indicate if any dependencies aren't fulfilled and offer to |
| 19 |
auto-unmask them for you. |
| 20 |
|
| 21 |
I find it to be a best practice to make /etc/portage/package.keywords |
| 22 |
a directory, and create files inside for various purposes. I have a |
| 23 |
file to put keywords in there for arch testing purposes. I have a |
| 24 |
file called zautounmask, which is where portage will dump auto-unmask |
| 25 |
settings (since it is last alphabetically). Over time when you have a |
| 26 |
million entries in these files having them separated will tend to make |
| 27 |
it a lot easier to clean them up. I can delete my auto-unmasked |
| 28 |
entries at any time and portage will just re-create the entries it |
| 29 |
actually needs the next time I do an update. |
| 30 |
|
| 31 |
Note that in general Gentoo doesn't do QA around mixed keywords. |
| 32 |
Typically it works fine, but you will run into exceptions. You'll be |
| 33 |
less likely to run into issues if you avoid running mixed keywords on |
| 34 |
things like core dependencies. You won't have trouble in general |
| 35 |
finding people to help, but ultimately nobody is going to officially |
| 36 |
bend over backwards to make it work. If you can identify what is |
| 37 |
causing a problem there is a decent chance it will get fixed (assuming |
| 38 |
upstream is cooperative - if some package doesn't work with a newer |
| 39 |
dependency upstream might just say they can't be bothered to fix it |
| 40 |
and it might not be easy to patch on our end). |
| 41 |
|
| 42 |
-- |
| 43 |
Rich |
Archives