Hello All,

What do you think about converting pkg overlay into an operational local 
overlay 
that has the same meaning for the portage as all the local overlays are? 

I understand that at a distant point in time some of the kept packages in this 
overlay will
not be supported by the current portage snapshot because of the lack of 
backward compatibility, 
but it will be useful in many many cases before that happens.

In some worst scenarios of outdated system - you can always edit pkg ebuilds 
manually 
to restore portage EAPI compatibility. 

A great improvement in my point of view. If some packages are removed/deleted 
or not supported 
by the new tree we won't have any dead locks. And you can almost always 
re-configure the 
installed packages because you have everything you need if you don't clear 
distfiles folder. 

As a further development we could keep /var/db/repos/local/eclass/ snapshots in 
the pkg tree
then we can fall back in case of EAPI not supported to the older eclasses and 
only 
have deadlocks if Python is not compatible any longer and we don't have any old 
version left
installed that supports eclasses (a very rare case).

And when that happens Gentoo will be very flexible to update from almost any 
point. And that 
will fix the problem that is with Gentoo from the moment of creation. IMHO it 
happened because
pkg DB was initially not a overlay which it should have been from the 
beginning. 

It logically follows that pkg is an overlay but only it's not which caused 
various problem with 
system architecture over the years, especially with updates. 

Do you see any fundamental problems of not fixing it at this point?

-- 
Best regards,
 Igor                          mailto:[email protected]

Reply via email to