| 1 |
> The simplest way to take care of it is to run an emerge -up and then |
| 2 |
> perform an emerge inject for any packages that would be downgraded. This |
| 3 |
> will prevent it from happening on this merge and on into the future -- |
| 4 |
> until another version of the package is released. |
| 5 |
|
| 6 |
I've never tried this because i heard that it cause some problems later... |
| 7 |
i think when the real packages are updated or something like that... Is it |
| 8 |
a safe method? |
| 9 |
|
| 10 |
> Aside from that, you're going to have to sit tight. You are, after all, |
| 11 |
> running development packages and as such have taken on the added burden |
| 12 |
> associated with that choice. |
| 13 |
|
| 14 |
I don't agree with you on this one, if i was modifying the package.mask |
| 15 |
file for experimental/broken packages (like i do sometimes) i would |
| 16 |
understand. However for unstable package that are part of Gentoo i don't |
| 17 |
understand why i would have an added burden. Stable and unstable packages |
| 18 |
are standard function in Gentoo so i don't think it's an excuse to lack |
| 19 |
the functionnality to handle them well. Debian doens't restrict you for |
| 20 |
this, neither does Red Hat or Suse, etc... Especially in the case of |
| 21 |
Gentoo that defines itself as a bleeding edge distro. I just want to say |
| 22 |
that i understand that developers don't have time to implement all the |
| 23 |
functions at once but i think that it's not a normal behavior in it should |
| 24 |
be fixed in the future... |
| 25 |
|
| 26 |
|
| 27 |
|
| 28 |
-- |
| 29 |
gentoo-dev@g.o mailing list |
Archives