1 |
hmmmm that looks exactly like what i'm searching for! I'll try it as soon |
2 |
as i get home. |
3 |
|
4 |
thanks! |
5 |
|
6 |
> You can "pin" a package. Just put ">=app-grp/appname-x.y.z" into |
7 |
> /var/cache/edb/world and emerge -u world won't try to downgrade, or use |
8 |
> = instead of >= and it will never try to change the version at all. |
9 |
> |
10 |
> Caleb |
11 |
> |
12 |
> On Thu, 2003-01-30 at 14:18, Louis-Philippe Brochu wrote: |
13 |
>> > One way to do it: remove whatever packages you do not want touched |
14 |
>> by "world" out of /var/cache/edb/world. The packages in that file |
15 |
>> are the only ones that will get looked at whenever you run 'emerge |
16 |
>> -u world'. |
17 |
>> |
18 |
>> Well there is two problems with this approach. First one is that by |
19 |
>> removing this package from the world file it will not be updated |
20 |
>> anymore when a new version (newer than the one installed) is released. |
21 |
>> Second problem is that this hack won't work if the package removed |
22 |
>> from the world file is required as a dependency for another package |
23 |
>> you're trying to install. Portage will resolve the denpendency, will |
24 |
>> want to install your package and will downgrade it. |
25 |
>> |
26 |
>> > Secondarily, I suggest running 'emerge -up world' to see what would |
27 |
>> be downgraded first, without actually running anything. |
28 |
>> > |
29 |
>> > Automatic downgrading is generally healthy behavior (if for example, |
30 |
>> we unmasked a new version which later proved broken/unstable, |
31 |
>> therefore we need people to revert to an older, stable release). |
32 |
>> |
33 |
>> Yes but there should be a way to disable this. An option to "pin" a |
34 |
>> minimum version of a package or to simply disable the possibility of |
35 |
>> downgrading a package (with a switch on the command line or better, a |
36 |
>> configurable option in /etc/make.conf). |
37 |
>> |
38 |
>> The case you are talking about *should* pratically never happen if |
39 |
>> packages we're tested *before* being released. |
40 |
>> |
41 |
>> > This is a FAQ... I'm sure there are some enhancements to Portage |
42 |
>> underway which will make this issue more elegant/intuitive. |
43 |
>> |
44 |
>> I really hope the Gentoo developpers will add this functionnality. |
45 |
>> Ever since the introduction for the ~arch keywords packages updates |
46 |
>> have been a mess for me. If you are running on a stable system |
47 |
>> exclusively everything is fine. Same thing if you are running |
48 |
>> exclusively with an unstable system (with ~arch). If you never use the |
49 |
>> emerge world command you should not have many problems, just define |
50 |
>> the ACCEPT_KEYWORDS before emerging unstable packages and you're ok. |
51 |
>> |
52 |
>> The problem comes when you are using stable *and* unstable *and* |
53 |
>> emerge world command. Try to emerge world a mix of stable and unstable |
54 |
>> packages and see all the packages downgrades. Try to define |
55 |
>> ACCEPT_KEYWORDS, now Portage wants to install all unstable packages. |
56 |
>> Mask the old version of unstable packages you installed (or just |
57 |
>> remove them from the world file) and watch Portage trying to resolve a |
58 |
>> dependency for another packages and downgrade your package anyway... |
59 |
>> The only thing Portage need is a "don't-ever-downgrade-my-packages" |
60 |
>> function IMHO. |
61 |
>> |
62 |
>> |
63 |
>> |
64 |
>> -- |
65 |
>> gentoo-dev@g.o mailing list |
66 |
> -- |
67 |
> /*--------------------------------------------------------------------- |
68 |
> Caleb Shay "UNIX _IS_ user friendly. |
69 |
> Programmer/System Administrator It's just particular about |
70 |
> Providence, RI who its friends are." |
71 |
> ---------------------------------------------------------------------*/ |
72 |
> |
73 |
> |
74 |
> -- |
75 |
> gentoo-dev@g.o mailing list |
76 |
|
77 |
|
78 |
|
79 |
|
80 |
-- |
81 |
gentoo-dev@g.o mailing list |