If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
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.
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.
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
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?
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.
Comment