| 1 |
On Thursday, 7 May 2020 04:50:41 BST Caveman Al Toraboran wrote: |
| 2 |
> On Thursday, May 7, 2020 7:31 AM, Dale <rdalek1967@×××××.com> wrote: |
| 3 |
> > Rich Freeman wrote: |
| 4 |
> > |
| 5 |
> > OP, odds are the emerge failure is what triggered the problem. If it had |
| 6 |
> > completed without failure, it would likely have been a clean update. This |
| 7 |
> > is why I set up a chroot and do my updates there and use the -k option to |
| 8 |
> > install on my actual system. It takes very little time and so far, no |
| 9 |
> > breakages on my real system. If any thing fails, it's more likely to be |
| 10 |
> > in the chroot which won't hurt anything. If you able, may be a option |
| 11 |
> > worth thinking about for yourself as well. |
| 12 |
> > |
| 13 |
> > Dale |
| 14 |
> > |
| 15 |
> > :-) :-) |
| 16 |
> |
| 17 |
> ya. i said it already. emerge's update failed |
| 18 |
> with some package midways (some package needed |
| 19 |
> some USE flag change), but then layman stopped |
| 20 |
> working in this incomplete state. |
| 21 |
> |
| 22 |
> also the issue was simple. but i pointed out that |
| 23 |
> the inconvenience of having a fancy dependency on |
| 24 |
> a pms is still there. |
| 25 |
|
| 26 |
Our portage sync cycles are different. I updated some python packages during |
| 27 |
yesterday's resync on a stable system. Today there was no packages needing |
| 28 |
update, but portage was unable to resolve layman: |
| 29 |
|
| 30 |
====================================================== |
| 31 |
These are the packages that would be merged, in order: |
| 32 |
|
| 33 |
Calculating dependencies \ |
| 34 |
|
| 35 |
!!! Problem resolving dependencies for app-portage/layman from @selected |
| 36 |
... done! |
| 37 |
|
| 38 |
!!! The ebuild selected to satisfy "app-portage/layman" has unmet |
| 39 |
requirements. |
| 40 |
- app-portage/layman-2.4.2-r1::gentoo USE="git -cvs (-darcs) (-g-sorcery) -gpg |
| 41 |
-mercurial -sqlite -squashfs -subversion -sync-plugin-portage -test" |
| 42 |
PYTHON_TARGETS="-python3_6" |
| 43 |
|
| 44 |
The following REQUIRED_USE flag constraints are unsatisfied: |
| 45 |
python_targets_python3_6 |
| 46 |
|
| 47 |
The above constraints are a subset of the following complete expression: |
| 48 |
any-of ( python_targets_python3_6 ) |
| 49 |
======================================= |
| 50 |
|
| 51 |
|
| 52 |
Python3.6 is still installed so layman works as intended and in the near |
| 53 |
future when >=layman-2.4.3 is stabilised in the tree, a regular update will |
| 54 |
resolve the above issue. Since neither layman nor portage are functionally |
| 55 |
borked, I don't perceive the above as a problem. |
| 56 |
|
| 57 |
Nevertheless, I followed the original thread with interest. Technology and |
| 58 |
programming languages evolve apace, so I understand a PMS running on python |
| 59 |
for decades may be deemed suboptimal today, if other more suitable solutions |
| 60 |
are now available. Unless someone skilled in those hypothetically better |
| 61 |
technologies rocks up and contributes, something I think most would welcome, I |
| 62 |
don't see the portage 'solution' moving away from python soon. I understand |
| 63 |
Paludis was such an endeavour, but its attempt to dethrone python didn't |
| 64 |
survive the test of time - or was it internal politics? |
| 65 |
|
| 66 |
I am less exercised regarding the static Vs dynamic libraries argument, which |
| 67 |
I also followed in the thread. I don't recall portage breaking here in what |
| 68 |
must have been hundreds of upgrades on mostly stable systems, for more than 17 |
| 69 |
years. What I'm saying is, it has worked for me and I thank the devs and |
| 70 |
maintainers for a job well done. :-) |
Archives