1 |
Hello All, |
2 |
|
3 |
What do you think about converting pkg overlay into an operational local overlay |
4 |
that has the same meaning for the portage as all the local overlays are? |
5 |
|
6 |
I understand that at a distant point in time some of the kept packages in this overlay will |
7 |
not be supported by the current portage snapshot because of the lack of backward compatibility, |
8 |
but it will be useful in many many cases before that happens. |
9 |
|
10 |
In some worst scenarios of outdated system - you can always edit pkg ebuilds manually |
11 |
to restore portage EAPI compatibility. |
12 |
|
13 |
A great improvement in my point of view. If some packages are removed/deleted or not supported |
14 |
by the new tree we won't have any dead locks. And you can almost always re-configure the |
15 |
installed packages because you have everything you need if you don't clear distfiles folder. |
16 |
|
17 |
As a further development we could keep /var/db/repos/local/eclass/ snapshots in the pkg tree |
18 |
then we can fall back in case of EAPI not supported to the older eclasses and only |
19 |
have deadlocks if Python is not compatible any longer and we don't have any old version left |
20 |
installed that supports eclasses (a very rare case). |
21 |
|
22 |
And when that happens Gentoo will be very flexible to update from almost any point. And that |
23 |
will fix the problem that is with Gentoo from the moment of creation. IMHO it happened because |
24 |
pkg DB was initially not a overlay which it should have been from the beginning. |
25 |
|
26 |
It logically follows that pkg is an overlay but only it's not which caused various problem with |
27 |
system architecture over the years, especially with updates. |
28 |
|
29 |
Do you see any fundamental problems of not fixing it at this point? |
30 |
|
31 |
-- |
32 |
Best regards, |
33 |
Igor mailto:lanthruster@×××××.com |