Dependency hell rabbit hole (yum)

OK - not sure how much anyone here can be of help - given I’m just about the only user here of RPM based distros…

Unable to patch a pair of CUPS servers - due to multi-lib… they’re running Oracle Linux 7… the only enabled repos are Oracle’s public yum, and epel (via the mirror hosted at aarnet).

I suspect what’s happened, I’ve installed some i386 libraries when I’ve installed packages for Brother printers… DAMN! But now that’s broken yum completely… Can’t update…

I’ve cloned the non-prod one to a sandpit instance, and I’m going to try purging i386 - then install later drivers for these brother printers :


I’m assuming these are Brother printers - as that naming convention looks familiar…

Wish me luck… The damnedest thing is - I can’t really test properly… All theBbrother printers are hundreds of kilometres away, some over a thousand! West Australia can fit Texas in the small change pocket of its jeans :smiley:

Strike that! I’m just going to tell the customer we can’t patch… The VERY VERY latest drivers from the vendor - come as i386 rpm files - there’s NO x86_64…

I use i386 drivers (as .deb file) for my Brother printer. They work in 64 bit Linux provided it has multiarch … at least it works for me in Debian, Devuan, MX, and Void.
You should be able to use the 32bit .rpm drivers. There is not much difference between .rpm and .deb… they are just archives containing tarfiles and some scripts.

i386 and i686 are preventing me updating the system…

I want to remove them… but I can’t… because there are actual brother printers out there in the field, using those i386 driver.s…

It might be possible to take the drivers out of yum control and install them somewhere else like /usr/ local. You might need some links from /usr/lib to /usr/local/lib so that cups can find all the stuff it needs to make print. … Not easy, and even less easy at a distance.

When you’re in a team - you can’t do stuff like that… Stuff has to be pretty close to stock standard, soon as you start veering away from that you end up with nightmare stuff… that’s a pretty tall ask when customers refuse to pay for licenses - and - the time to implement - things like SOE/MOE for Linux server builds and configuration management tools (like Ansible or Puppet). Fair enough I’m the main “primary” for this customer, but, what happens in the “hit by bus” scenario? Yeah - I document it - sure - but what happens when someone else like me comes along, assumes there’s no doco (which I do all the time) and break it?
Anyway - I’ve got a sandpit, I’m going to try removing and purging those i386 and i686 packages then take a look at what happens - maybe update without those brother drivers, then try to re-install them.
If that doesn’t work I’m just going to put a big red X next to both boxes : “we don’t patch these”… There’s already a whole fleet of servers we don’t patch 'cause the application vendor only supports their product on platform X, version Y, release Z - and another platform that’s 100% controlled and stood up by a KVM deployment suite that enforces configurations, patching it would break everything.

I understand that… and hate it.

Anyway - I’ve got a sandpit, I’m going to try removing and purging those i386 and i686 packages then take a look at what happens - maybe update without those brother drivers, then try to re-install them.

That makes sense. Note purge does not always do a clean job

I dont understand why those brother drivers would upset the packsge system. they do put files in /usr/lib or /usr/lib64 that are not controlled by the package system, but the only thing that complains about that for me is ldconfig

Update : yum remove *i686 seemed to work - and it’s now letting me “yum update” - I always save the first run of “yum update” to a transaction log, then replay that transaction log. Once it’s done, I’ll reboot and see about re-adding those Brother RPM files… Note - the versions I installed yonks ago, are the same ones I downloaded from Brother - so Brother haven’t updated their drivers for these for a few years, at least.

yum update --assume-no
(will create a transaction log in /tmp, but won’t update anything)
then :

yum -y load-transaction $PATH/$TransActionLog

This feature is exceptionally useful when e.g. patching Test in Week 1, then Prod the week after - run “yum update --assume-no” everywhere, and you’re applying the same set of patches at that point in time across the whole fleet of servers. I’ve no idea if Debian or Ubuntu or other DEB flavours have that feature or not, don’t manage enough of them for it to be a major issue (which is not quite true - as I “manage” a bunch of them at home!).

package-cleanup --oldkernels --count=1 -y
reboot then :
yum --nogpgcheck localinstall mfcj6930dwlpr-1.0.1-0.i386.rpm mfcj6930dwcupswrapper-1.0.1-0.i386.rpm mfcl3745cdwpdrv-1.0.2-0.i386.rpm

And that seemed to work. But still have to verify if the CUPS test pages came out 1500 km away in the three regional offices.

One thing I hate about CUPS server configuration - all the access stuff you have to tweak in /etc/cupsd.conf (e.g. it even usually has it’s IP hardcoded in there, so if you change IP address - you have to remember to update that config file).

Same with my Brother printer… been using same printer drivers for at least 10 years.
printer drivers are i386, but scanner drivers are amd64… strange.

I think I prefer my updates one at time. I can see the point with a whole fleet of servers.

CUPS is difficult enough in a single machine.

Did you work out why yum would not update with i686 packages present? It must scan
either the yum database or /usr/lib looking for rogue packages? I have occasional trouble in Debian with an update wiping out the printer drivers, but it does not stop the update. I just reinstall the drivers if that happens.

No - I lumped that into the ‘too hard basket’ and did the “remove ALL 32 bit stuff”… Shotgun blast VS targeted sniper shot…

My Ubuntu (i.e. Ubuntu and PopOS) systems are using the 64 bit driver that seems to be built into the OS - i.e. as mentioned in other posts - I NEVER have to even manually install anything - the system just goes out there, scans my LAN and installs drivers and I never have to lift a finger… More plug and play than anything in Windows or MacOS!

http://localhost:631/ tells me my Brother is setup “driverless” :

I don’t know how that works, nor do I care, 'cause it just works… Not that I print very often, I vastly prefer the “Paperless Office” concept. And I don’t worry about scanner driver, as I scan direct to FTP on my NAS.

Thats the new printing standard. Its a bit like the old postscript printers, the intelligence is built into the printer, only you dont have to send it a postscript file, you can send it anything…
So CUPS doesnt do much, except spool it.

Confirmed at the regional offices at the top end of West Australia (Kimberley / Pilbara) test prints on Brother printers received after removing, patching, rebooting, re-installation… nearly 3000 km away (Kununurra) - I wish my boss would pay for me to fly up there and verify myself :smiley: … Broome… yeah - a couple of days in Broome would suit me just fine - but my boss is a tightarse and that will never happen :smiley:
How many Texas’s is Western Australia ? :


Might be a bit wet at moment.

How many Texas’s is Western Australia ? :

There used to be a thing at school… how many maps of UK would fit into Ausrralia.
I forget the answer.

I wouldn’t care… just to get out of town for a bit… and get paid for it :smiley:

When I was teenager I was obsessed with the map of Tasmania… (there’s a euphemism in there, releated to the shape of Tassie :smiley: )…

1 Like

I used to do field trips. mostly to do sheep work. Yes paid a travel allowance. Did so much I got sick of it in the end

In 30+ years of IT - in many cases with customers or sites across the whole state of Western Australia, I’ve only got remote site travel once - and that was a coal mine in a coal mining town - BORING! And it was a hire car, 3 hour drive, stay in a motel… Ho hum…

1 Like

Travel is the wrong way.
To appreciate a remote site, go and live and work there for an extended period. It is entirely different to breezing thru on a work trip or a holiday.