Where ist package dri-11.2.2,2?

Hallo!

I need the above package or an upgrade of it!

Since firefox was making core dumping, I did pkg install firefox for upgrading it.

It began to upgrade firfox, and at one poing begant to umpgrade more (as I remember), and there were a conflict with dri-11.2.2,2 and mesa-dri-17.1.4. I deleeted the first and installed the second.

After I reboot, I could not start the X server, after xinit I got:

Code:
/usr/local/lib/libgbm.so.1 : Undefined symbol drmGetdevice2

Then I deleted xorg and a lot of other things, among them mesa-dri-17.1.4, for reinstalling them.

Now I can start then server, run firefox for search with google and ask here, but: ksm does not work, and even with X11 I have awfull fonts.

Thanks for any hint.
 
I solved the problem with the kms and the awful fonts with

pkg install xf86-video-ati-7.9.0_1,1

I wonder why this was not reinstalled automatically with xorg.

I ask me, if there are not other inconsistencies.

But the problems began with the failing of pkg install firefox.

These are nothing else than BUGS. And they mean wasting of time and nerves when one has other things to do.
 
The x11/xorg package/port is a so-called meta-port. It doesn't contain anything of itself and only depends on other ports/packages. Uninstalling and reinstalling it does absolutely nothing because all the dependency ports/packages are all still installed.

This is not a bug, this is simply a failure in understanding how meta-ports work.
 
But I uninstalled and did pkg autoremove, then I installed again.

Does this do absolutely nothing? I did not get this impression.
 
The autoremove did, yes, but you didn't mention running it. Simply running pkg delete xorg && pkg install xorg won't do much.
 
Well, but the BUG is something else. Please, see the chronologiy above. I did pkg install firefox for upgrading it. It began to upgrade the system and it failed because of a a conflict with two packages. I deleted the one in the system and installed the one required. All that were normal commands. This should have worked, but I ended with a brocken system. Also that reinstalling xorg didt bring the ati driver seems to be a bug.
 
Before installing something new, or if you just want to update what you have, run pkg upgrade. You need to make sure your system is completely up to date. If you have some old packages and you install something new all sorts of dependencies will get mangled. Regularly read /usr/ports/UPDATING, even if you only install packages, then run pkg upgrade or follow the instructions from UPDATING. Sometimes ports, and by extension packages, need to be updated in a specific order.
 
Also that reinstalling xorg didt bring the ati driver seems to be a bug.
Not at all. Do you see x11-drivers/xf86-video-ati included anywhere in here (or here, or here)?

The only two video drivers that are installed by default are the bare minimum drivers - x11-drivers/xf86-video-scfb and x11-drivers/xf86-video-vesa - that can be used as fallback drivers.

pkg(8) is a utility that manages packages and nothing else. It's not supposed to detect the model of your graphic card.
 
SirDice, I see. When installing (or updating), updated depencencies may be necessery, and then also the packages that depend on them may need to be updated, and so on. A chain reaction. But is this problem not solved automatically? As I remember, after doing pkg install firefox, the upgrading began automatically, and this does not happen with every pkg install.

Under these circumstances, for avoiding upgrades or at least making them faster, for avoiding risc of breaking a working system, it is prudent to avoid a large number of dependencies, or big dependencies (like texlife). It would be nice to have many flavours of packages. I would propose: cool nonplusultra bloat with all possible dependencies, bloated for Gnome users, bloated for KDE users, for plain X11 users, for command line users, most meager for ascetics.

scottro, your link points to this very same thread.

Beastie, I do not remember to have installed xf86-video-ati-7 before the system broke, and I did not deinstall it explicetly after that. I suppose it was a dependency that was removed with pkg autoremove.
 
But is this problem not solved automatically?
Only up to a certain point if you update a single port. That's why it best to pkg upgrade so everything is updated.
Under these circumstances, for avoiding upgrades or at least making them faster, for avoiding risc of breaking a working system, it is prudent to avoid a large number of dependencies, or big dependencies (like texlife).
Not if you keep your systems updated regularly. Then it's never a really big step, just lots of small ones.

It would be nice to have many flavours of packages.
Yes, that's nice to have but a lot more difficult to actually implement and, more importantly, maintain.
 
suppose it was a dependency that was removed with pkg autoremove.

Hi hruodr, it's practically sure things have gone that way. When you run pkg autoremove, it removes all the orphaned packages. This means that if you removed a package (in this case graphics/dri) which you had installed through pkg install, then running pkg autoremove shall remove all the dipendecies that came along with that package.
As you can see for dri, it's dependecies were many: http://www.freshports.org/graphics/dri
It's therefore understandable that xorg wouldn't have started afterwards.
So it is highly advisable to check thoroughly which packages autoremove asks you to delete.

It's really strange that you don't know how you got the ATI driver installed. No port depends on it, so you certainly didn't install it as a dependency with pkg. What video card do you have and what driver does xorg normally use?
If you needed it in order to launch xorg, but you don't remember ever installing it, and you didn't modify anything inside /usr/local/etc/x11/xorg.conf.d/ either, then probably xorg just needed the dependencies that came with x11-drivers/xf86-video-ati in order to avoid that run-time error.
 
then running pkg autoremove shall remove all the dependencies that came along with that package.
Unless some other package depends on it.

For example, PackageA depends on PackageB. If you install PackageA PackageB is installed automatically. When you remove PackageA, PackageB will be 'orphaned' and removed with pkg-autoremove(8). But suppose you also installed PackageC, which also has a dependency on PackageB, the removal of PackageA will not cause pkg-autoremove(8) to remove PackageB because PackageC is still depending on it.
 
Unless some other package depends on it.

For example, PackageA depends on PackageB. If you install PackageA PackageB is installed automatically. When you remove PackageA, PackageB will be 'orphaned' and removed with pkg-autoremove(8). But suppose you also installed PackageC, which also has a dependency on PackageB, the removal of PackageA will not cause pkg-autoremove(8) to remove PackageB because PackageC is still depending on it.

True, thanks SirDice, It didn't even came to my mind while I answered. Guess it's been a while since I installed a package last. If what I said were true then running autoremove would be indeed extremely troublesome. Fortunately it's not
Best regards
 
Back
Top