# Portage perl and FGLRX and ... deprecated?

## eccerr0r

The "recent" (dangit, yes I put it off...) stabilization of xorg-server-1.18 seems to have caused one heck of a lot of problems to my fglrx/ati-drivers box.  Some of the problems included for whatever reason, the perl 5.20 to 5.22 update which portage got really confused about.

However after adding these masks:

>x11-base/xorg-server-1.17.49

>=x11-drivers/xf86-input-evdev-2.10

>=x11-base/xorg-drivers-1.18

even my perl problems in portage(2.3.0) went away automagically.  I don't claim to understand why this fixed it but it did...

In any case I've heard that ati-drivers is pretty much deprecated now?  Even for RadeonHD 5000-series GPU?

I'm still using an old RadeonHD 5770, and for now "just works" but perhaps I should switch to the OSS driver soon?  Is it stable?  All functionality backported to this old GPU?  Including OpenCL?

[EDIT]

I just had another box that had a very strange perl slot conflict problem upgrading from 5.20 to 5.22.  There was another block (grub-0 and grub-2), so I fixed one block by masking (>=grub-2), and magically the perl problem went away(!!!)

So it almost seems there's a portage bug here unless I'm missing something here, or at least the portage output is not clear what the real problem is...

[EDIT 2]

ANOTHER box I had fglrx installed upon and ALSO had grub0 installed.  Masked the new versions of xorg-server that fglrx didn't like and ensured grub2 was masked, and magically perl slot conflict went away! 

This box I was pretty close to (and probably will still do so) emerge --unmerge ati-drivers as it was causing the xorg blocks.  I don't even have an ATI board in that box anymore, but left the driver there just in case... but all it's doing now is causing blocks...

----------

## v_andal

Well, I'm not very happy about conflict between newer xorg and fglrx but really, it did not prevented me from updating perl. Yes, there were conflicts but I could resolve them by manual updating of various perl modules. Perl is famous for causing blocks during update. Usually, these blocks happen because there are so many different modules for perl. It is not a "portage bug". It is rather "bug" of the perl ebuild, but I guess it is not so easy to track every single perl module that depends on perl.

So, I haven't masked newer xorg or anything else yet, I've just manually updated perl and now wait on what is going to happen about fglrx.

----------

## asturm

Perl upgrades usually 'just work' these days as long as you do not have a mix of ~arch and arch packages installed.

fglrx is gone, dead, for good, it will not see another release from AMD. Switch to radeon and never look back.

----------

## eccerr0r

Yeah I've gotten a lot of slot conflicts on perl lately, but it was strange that all the slot conflicts "went away" when a seemingly totally unrelated block was resolved via masks.  The reason why it seems like a portage bug or perhaps needs to be a portage enhancement is that if it was able to resolve the slot conflict after fixing the block, why did it give the error to begin with?  And why didn't it fix it on its own?   The manually masked packages were not unstable versions.

Maybe there was some hidden perl dependency on the block?  But not sure, thought that grub and fglrx don't need perl...

---

It looks like that Ubuntu has deprecated fglrx, but AMD still hasn't totally given up on it, but the plan is to give up on it.  The last fglrx release is almost a year old now, so yeah looks like it's almost dead.  Will have to look into switching to amdgpu soon, hoping it's equally as good^H^H^H^H^H fast...

----------

## eccerr0r

Tried updating yet another box...this time with nvidia-drivers <341 .. same xorg-1.17 requirement, same perl-core slot conflict.  There was also another block with tigervnc-1.6 that requires xorg-1.18.

I was thinking, ugh more perl-core slot conflicts...but maybe it could be fixed with fixing the other blocks.

I masked xorg-1.18 as the ati boxes...and lo and behold, the perl slot conflicts went away!

Weird.

----------

## asturm

Portage is very verbose in those cases; when it quits on a conflict, it shows all those others as well that it actually is able to auto-resolve. It's a good idea then to watch out for the capital 'B' in the packages list that signals a real blocker.

----------

## eccerr0r

I'll see if I have any more machines with perl slot conflicts that won't autoresolve without masking Xorg 1.18 and post the exact error, seems I had no less than 4 machines so far with the same problem.  They all are showing up as slot conflicts for perl and version conflict (this package needs version X but this other set of package needs version Y) for the other packages.  These aren't don't seem to be hard blocks per se, but rather just a conflict... just that there seems to exist a solution that meets all constraints (without using ~arch), if and only if some of the latest versions are ignored.

Also tried --backtrack 300 and even that didn't do anything.

----------

## Zucca

 *asturm wrote:*   

> fglrx is gone, dead, for good, it will not see another release from AMD. Switch to radeon and never look back.

 ... and in most cases the open source radeon is in par with fglrx.

----------

## eccerr0r

Looks like someone ran into the same issue that I did:

https://forums.gentoo.org/viewtopic-p-7984119.html#7984119

Here you can see the xorg and ati-drivers slot conflict for 1.17 and 1.18 (expected as it's part of the ebuild) but the perl slot conflict I think is spurious.  We'll see if mgnut57 is also able to resolve the perl slot conflict by simply masking xorg, too...

----------

## mgnut57

 *eccerr0r wrote:*   

> We'll see if mgnut57 is also able to resolve the perl slot conflict by simply masking xorg, too...

 

I was. 

I did update portage before trying a world update. I usually do this as quite often conflicts get fixed with an update to portage.

----------

## asturm

Several people wrongly thinking they have a perl upgrade issue when it really is a severely outdated nvidia-drivers package or dead fglrx on the xorg-server upgrade... bad timing.

----------

## eccerr0r

 *asturm wrote:*   

> Several people wrongly thinking they have a perl upgrade issue when it really is a severely outdated nvidia-drivers package or dead fglrx on the xorg-server upgrade... bad timing.

 

But why is Portage giving incorrect data?  It shouldn't give out the perl problem.

----------

## asturm

It's not incorrect per se, it's a conflict as well that it is able to fix by itself. Any solution to this would need to be extra careful to not hide real issues instead.

----------

## eccerr0r

It's unnecessary data that can throw off the debugger - which indeed it does.  Ideally it should give out the most important errors first - but perl shows up on top.

This and the fact that if xorg was automatically "held back," this should have been automatically resolved by portage without user intervention as there indeed a solution that exists with only stable packages.

Must be some heuristics involved that force certain packages...

----------

