Mesa Eyes Pulling libdrm Into Its Codebase

[Danny3]

Oh, come on!

Is this really needed for Linux?
If yes, why it has not been done already?
Or Microsoft got this guy too?

[jonix]

normally im not a fan of these uber package style things, but considering libdrm is tied pretty closely with mesa anyways I don't mind it. for those who want a seperate solution, minidrm is always a thing

I believe this is the right way of seeing this proposal. But if the mesa drivers really have diverging version requirements for libdrm this may cause some headaches in the short term. I am sure Marek have considered this, but I am still concerned.

[cj.wijtmans]

He even invented a time machine and infected the BSD's and GNU from before he was able to even code.

The problem existed here and there but it was not that common, poetering just took it to a completely new level and normalized it.

[cj.wijtmans]

Please explain exactly which part of the PKGBUILD file is objectively a hack and not just like your opinion, man. I'm searious.

Your linked Reddit post has nothing to do with this, installing two different versions of the same dependency is an issue that arch just doesn't allow in general without workarounds.

that is not a problem in gentoo and other distros, you can have multiple version of the same library as long as the library is versioned properly and there is no inherent incompatability issue. The issue here is the BUNDLED library. I think you are not seeing the issue here.

[tildearrow]

Typo:

This merge request was opened a few days ago with still neeeeding to update the continuous integration (CI) test scripts,

How?

[Veto]

its the poetering disease. systemd, mesa, gcc, linux, pipewire that are monolithic and many other packages that bundle libraries into their repositories even though they have their own main repo. It mgiht be fine for the average distro that can download the mono repo, update it, disect it into pieces to release the package. For gentoo that actually handles packages properly, its kind of a nightmare. Maybe its about time the average linux user abandons this corporate crap spaghetti code.

OR maybe you just don't understand the benefits for these big and prominent projects in bundling their dependencies. Maybe it is actually more efficient to bundle dependencies to be able to control compatibility and changes across interfaces. Maybe it really is impossible to make a sufficiently complex system consisting of a hodgepodge of disjoint components, libraries and modules without any strong coordination and made by software engineers with varying degrees of respect for API stability and the needs of their dependants.

As we are not the ones doing the work, we can only wonder

[You-]

The problem existed here and there but it was not that common, poetering just took it to a completely new level and normalized it.

the BSD's are not just "here and there". GNU coreutils is also many utilities developed in a single repo. Even xfree86 and then xorg had a monorepo.

Mono-repos were the norm.

[cj.wijtmans]

OR maybe you just don't understand the benefits for these big and prominent projects in bundling their dependencies.

laziness is not a benefit. I understand why they do it, you just assume i dont.
(how often i pondered wether to use git modules or git subtree.)

Maybe it is actually more efficient to bundle dependencies to be able to control compatibility and changes across interfaces. Maybe it really is impossible to make a sufficiently complex system consisting of a hodgepodge of disjoint components, libraries and modules without any strong coordination and made by software engineers with varying degrees of respect for API stability and the needs of their dependants.

In my own large projects i seperate the code just fine. i have a dozen libraries seperated and the main project into 3-5 parts. So i can reuse my code in other projects down the road. Why cant other projects with more man power do it?

As we are not the ones doing the work, we can only wonder

speak for yourself.

[guglovich]

And then it'll be like systemd

[oiaohm]

laziness is not a benefit. I understand why they do it, you just assume i dont.
(how often i pondered wether to use git modules or git subtree.)

In my own large projects i seperate the code just fine. i have a dozen libraries seperated and the main project into 3-5 parts. So i can reuse my code in other projects down the road. Why cant other projects with more man power do it?

There are issues you are not considering.

Something that happened a lot is distributions shipping to end users combinations of libraries that upstream have not tested.

One of the advantages of bundling like systemd does is that all the parts that were tested with each other in the automated testsuite by the make are shipped to distributions as one unified block.

Bundling like systemd does has a direct effect on reducing the number of bugs being submitted caused by distributions mixing new and old parts.

Remember even if you have more man power think about the number of uses something like Mesa has and how many can have distribution ship a new version of mesa with old version of libdrm then end up with a stack of bugs that have to be proceed. Avoiding this problem has some serous development time advantages.