1 |
On Fri, 2019-12-06 at 21:28 +0100, Thomas Deutschmann wrote: |
2 |
> On 2019-12-06 21:10, Andreas Sturmlechner wrote: |
3 |
> > Just so we're on the same page, a recent example of what some |
4 |
> > people |
5 |
> > suggesting to keep py27 ad nauseam are asking users to deal with: |
6 |
> > [...] |
7 |
> > WARNING: One or more updates/rebuilds have been skipped due to a |
8 |
> > dependency |
9 |
> > conflict: |
10 |
> |
11 |
> Yes, like said, at some point you cannot prevent that. Remember when |
12 |
> I |
13 |
> bumped libvpx to v1.8.0 and people yelled at me because they are now |
14 |
> seeing that message all the time (If you are using gnome you probably |
15 |
> know the same msg which triggers for unicode stuff which I am also |
16 |
> responsible for) because I bumped that package but not everything |
17 |
> supports that version yet? |
18 |
|
19 |
|
20 |
For having maintained packages that often have this issue for years, I |
21 |
must say this is a very bad idea: You are asking (or doing yourself) |
22 |
consumer packages to have < deps on your package. This falsely gives |
23 |
the impression that the non-latest version is still maintained. This |
24 |
also makes removing this old version very error prone (we do have tools |
25 |
to check for that but those are not in the standard workflow). Not sure |
26 |
how portage handles this, but negative deps (<, =, ! & co) are much |
27 |
harder to solve than purely positive ones -- PM probably uses some |
28 |
heuristics but then this has some limitations and if the number of such |
29 |
deps grows too much it may fail to solve them or do the right thing. |
30 |
|
31 |
I think it is a much better way to package.mask the newest version of |
32 |
your lib until all consumers work with it, or those that don't are |
33 |
masked. This is how we handled such transitions before portage improved |
34 |
its handling of negative deps and is IMHO still better. |
35 |
|
36 |
|
37 |
Alexis. |