Mesa Eyes Pulling libdrm Into Its Codebase

[uxmkt]

its the poetering disease.

Bundling (and, by extension, only giving care to a bundled fork) was a problem long before systemd. Google is an early culprit here (Chromium is also humongously big even if you ignore the entire third_party/ directory). And, in a sense, everyone who has had to build programs for Windows in the 90s and 2000s also bundled often and developed forks.

[vextium]

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.

With that logic, you'll have to abandon Linux too, since Linux is widely corporate backed, and with it, the code as well is widely corporate backed as well.

[LtdJorge]

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

Remember the famous Donald Knuth quote: "Lennart Poettering is the root of all evil"

[GreenReaper]

Remember the famous Donald Knuth quote: "Lennart Poettering is the root of all evil"

Yeah, but like... that's just his opinion, man!

[cj.wijtmans]

With that logic, you'll have to abandon Linux too, since Linux is widely corporate backed, and with it, the code as well is widely corporate backed as well.

and if you would know me you would have seen me criticize linux multiple times for this.

[cj.wijtmans]

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

and this should be the issue of disibutions being ass and not for code projects. In the same way we now accept that the issue is foremost for the compositor and not for the wayland protocol. As long as libraries version properly based on their ABI and code in a way that multiple libraries can coexist on the same OS (which is most libraries) there is no issue at all. As i said , pure laziness.

[oiaohm]

and this should be the issue of disibutions being ass and not for code projects. In the same way we now accept that the issue is foremost for the compositor and not for the wayland protocol. As long as libraries version properly based on their ABI and code in a way that multiple libraries can coexist on the same OS (which is most libraries) there is no issue at all. As i said , pure laziness.

Items like Mesa have people reporting performance issues when there is no ABI change. This idea of correctly versioning based on ABI gets you only 95% there is still 5% of hell issues.

Remember the test cases for the other mesa parts can find issues in libdrm patches that the libdrm direct test cases don't show a problem with.

This is not pure laziness.

Our source management systems don't clearly record test information. libdrm x version mesa y version where they in fact tested with each other? Before this merge you could not look at either source be it libdrm and mesa drivers and be sure they were tested with each other.

This is not just a distribution problem.

The advnatage for mesa is merging libdrm into mesa is that the over all mesa version now version of test result number. That all parts in this repo were all tested with each other.

Yes it one thing to say lazyness its another to look at facts.

https://abi-laboratory.pro/index.php?view=timeline&l=libdrm

Notice all the cases of new symbols being added.
Then notice when you look in deeper. That over 5 years there are 26 different version of libdrm and distributions can be shipping with 5+ year old plus parts. So does mesa need to test with 26 versions of libdrm every new core mesa modification or is merging so they can test with 1 version can call it done.

Then notice bits like libdrm_amdgpu.so.1.0.0 that there can be fixed in here to deal with issues found by the core amd driver in mesa.

Remember with git and other source management they don't include a feature to bundle up the information of what the parts has this source being tested with when the test suites have been automatically run by the upstream.

This is not lazyness the problem with distributions trying to use X program with Y library version when they should be using Z library version so it works instead of fails happens because the distribution packages don't have the information in clear to see way.

Bundling does address a problem. It also that we don't have a proper fix to this problem..

[cj.wijtmans]

Notice all the cases of new symbols being added.
Then notice when you look in deeper. That over 5 years there are 26 different version of libdrm and distributions can be shipping with 5+ year old plus parts. So does mesa need to test with 26 versions of libdrm every new core mesa modification or is merging so they can test with 1 version can call it done.
Then notice bits like libdrm_amdgpu.so.1.0.0 that there can be fixed in here to deal with issues found by the core amd driver in mesa.

Should be the problem of the distro not for mesa. If mesa wants they can dictate which libdrm version is required. And again you make the point of laziness because they cant automate testing for multiple versions? Give me a break.

Remember with git and other source management they don't include a feature to bundle up the information of what the parts has this source being tested with when the test suites have been automatically run by the upstream.

I am not sure what you mean here and why this should be gits responsiblity instead of the test suite?

This is not lazyness the problem with distributions trying to use X program with Y library version when they should be using Z library version so it works instead of fails happens because the distribution packages don't have the information in clear to see way.

Again the argument is for laziness, distro packaging software being ass, as i implied before.

Bundling does address a problem. It also that we don't have a proper fix to this problem..

yep it addresses laziness one way or the other, thanks for confirming.

[oiaohm]

Should be the problem of the distro not for mesa. If mesa wants they can dictate which libdrm version is required. And again you make the point of laziness because they cant automate testing for multiple versions? Give me a break.

Problem here is should be a distro problem but does that hold in the real world the answer is no. User will still report issues up stream directly going around their distribution support system. So issues distributions cause come upstream open source project problems like it or not.

Force dictating libdrm version inside mesa source has the nice little effect of
1) Limiting diagnostics.
2) Documented cases of distributions maintainers removing these limitations. This was clear demoed with the openssl security issues where distribution maintainers added patches to remove the software locking prevent old inscure versions of openssl from being used. Willful disregard of upstream even when it make sense..

Automated testing has a operating cost quite a lot when it comes to a item with mesa when you are talking about needing physical GPUs.

I am not sure what you mean here and why this should be gits responsiblity instead of the test suite?

Because we sure the distribution maintainers will not go to the upstream automated testing and get what is tested. That what they do.

You are kind right on

Again the argument is for laziness, distro packaging software being ass, as i implied before.

But you are not put up solution.

With current git libdrm bundled equals that the distribution maintainer when they download mesa they get correct libdrm as well. Since they have the correct version they are not tempted to build with the wrong version out of lazyness.

Current git and all other source management I have seen you don't have the option of /3rdparty/somelibrary and this somelibrary be download from a different repository with a particular version.

Another thing is not just laziness if it was it would be simple. Think distribution package maintainer is taking of care of 1000+ packages they don't have the time to be reading documentation or reading automated testsuite reports of upstream to see what is being used. Number of hours in day problem.

Like it or not the process to distribution maintainers need to be lazy because they don't have hours to spend because they are normally overworked.

Distribution maintainers are not just being ass. We need way to get the source the upstream has tested and approved to the distribution maintainer in a clean simple and fast way.

A lot of distribution maintainers have found systemd made their lives many time better due to the bundling. So they were not guessing if X part should work with Y part they just get handed everything.

There is a upstream stream advantage of merging projects that systemd was about as well. Lot of the packages merged into system the prior maintainer had disappeared or was no longer able to keep up. Reducing individual source trees by merging increase the number of people to process patches to that source also make authorization on who working on the source trees simpler.

cj.wijtmans you want to say the problem is laziness. The reality is like it or not we need to accept that merges like this will keep on going on while its not straight forwards for distribution maintainers to have the versions of parties they should be using dropped straight into their hands.

We cannot expect distribution maintainers to be reading lots of documentations and known custom unique stuff about every package they are taking care of. Basically we need a standard system for delivering to distribution maintainers what the upstream has tested and approved that is better than bundling.

We also have to accept that bundling provides upstream with advantage over current way of doing split repositories and be working out how to give the same advantage with split repositories to reduce the motivation to merge.

Yes adding means to go third party directory in git with links to other gits of fixed versions so that maintainers download git like mesa and the git of libdrm auto downloads as well so they have all the parts of the current version they should be using. Yes that would be the version of libdrm that the mesa automated test suite run on that version. Something like this would make it simple for the upstream mesa and the down stream distribution maintainers to stay on the same page and would also reduce the problems cause by incorrect versions because the lazy way would be use the correct versions.

This is the thing the simplest and lazy way need to be the way that has end users end up with correctly matched libraries and to get to this we need to improve our tools.