figure out which CDTs we can drop for cos8, maybe drop them all? #66
Comments
|
@conda-forge/core, I started with creating a list (based on the README, modulo aarches) and collecting some information (mainly based on the excellent pkgs.org). If you think additional information would be useful (and don't care if the table formatting looks bad), please tell me what else I should add or remove. If/once people agree on a format I can fill in the rest. PS. The separation into various areas is somewhat subjective, happy to reshuffle if people have better suggestions. |
X11
GNOME
Other Graphics (DRM, Mesa, OpenGL, etc.)
** needs: conda-forge/staged-recipes#25919 Other Hardware & Kernel Interfaces
System & Security Libs
Formats, Parsing & ImagesThis whole section should be replaceable with our own builds.
Fonts & Language
Web & Browser
Rest |
|
x11 can probably fully dropped. We've dropped all x11 from qt main's repo: |
|
@conda-forge/core, checking in here again - could people with opinions propose some ✅ / ❌ in the "keep as CDT?" column? (perhaps with a little abbreviation for your name, e.g. "Alice: ❌" or "Bob: ✅") Especially the ❌'s would be important, but also stuff we absolutely cannot move away from CDTs.
I mean we're all waiting for wayland to fully take over (right? 😉), though I guess you don't mean that we won't need x11 anymore (as a random example, there are >30 recipes still using the |
|
All of |
Thanks for the input! I updated the table above.
This query shows 26 recipes which use at least one of these directly, mostly expat. Another 8 feedstocks have at least one of them in |
|
With the May need to do some work to split outputs from rdma-core if needed. |
It's not immediately clear if they are direct or indirect because some CDTs don't have dependencies correctly and the maintainers have to add them to the recipe even though they are indirect. |
|
Speaking about HW interfaces, we can probably also drop Also, I'm pretty sure everything under "Fonts & Language" could be replaced (perhaps with the exception of |
|
Added a few more. Not positive whether we can drop the associated CDTs. So added question marks for now |
|
Tentatively marked the following as ❌ (principally because it's stuff we have feedstocks for, which should just work 🤞):
Plus added some more feedstock matches, resp. candidates. Seems we have pretty much all of X11 already built separately (principally by @pkgw it seems 🙏) Some near matches:
|
|
The conda-forge Mesa is complicated. Maybe we can look at |
|
This was again discussed in the core call today:
Overall, we're getting to the point where we've come to a decision (if preliminary) for ~80% of CDTs, so we should be able to restart working on the alma enablement (which is painful due to changed repo structure / urls), rebuild perhaps slightly more CDTs than necessary, and then try to move feedstocks over to using our own builds, and only falling back to CDTs if that runs into issues. |
|
Based on discussion at the core meeting it sounds like we are ok with the current list of CDTs So we should be good to start producing these cc @beckermr (for vis) |
|
That's not true. Please see the meeting notes. |
In the call, we did discuss how we're ready to start building all CDTs that aren't descoped in the mega-list above. We can still reduce that number later on if we prefer. The only open question was the effort around |
|
Right it was my understanding we were done updating the table and ready to make CDTs Could I ask that we spend the next week updating anything that still needs updates in the table? Would like to get consensus for moving forward on this issue in the next core meeting. So we can start making these |
|
Thanks @isuruf for filling out the table! Is there something particular about |
|
Also, I've now marked all the X11-related packages for which we have feedstocks as ❌ |
|
In today's core meeting, we decided to go ahead with any that have a ✅ |
|
A user recently wrote up a list of X11 packages we are missing: conda-forge/staged-recipes#26241 |
|
https://github.com/conda-forge/libglvnd-feedstock is implemented. All OpenGL CDT packages may be dropped completely. libgbm is part of Mesa, so it is required from there. However, as a substitute for Mesa CDTs, it is a good idea to implement Mesa with libglvnd linking support as well. |
Thanks Seungmin! 🙏
So would this mean updating the If this would be a new feedstock, maybe it would be a good idea to capture what is needed in a new |
|
We have about 130 feedstocks that use a yum-requirement that's either |
|
libglvnd does not require mesa during package build, and this is a key point this feedstock exists. However, during runtime, if libglvnd doesn't find a vendor library, it will error out. Basically, Mesa is only a requirement in some situations, which has never been fulfilled in Conda. Moreover, as stated, libgbm is part of Mesa so that should be handled. |
|
We don't need mesa in most packages that use mesa CDTs. Just replace with |
Initial attempt at such a change happening in PR: conda-forge/qt-main-feedstock#284 |
|
xorg-libxv, xorg-libxxf86dga, xorg-libxshmfence are new feedstocks or replacement feedstocks for CDTs. Other information on X11 packages and their revamp: conda-forge/staged-recipes#26241
|
I cannot find a single feedstock in conda-forge that uses |
|
xorg-libxv, xorg-libxxf86dga, xorg-libxshmfence are implemented and free for use in various feedstocks. |
|
xorg-libxv, xorg-libxxf86dga, xorg-libxshmfence are implemented and free for use in various feedstocks. These were important milestones for Xwayland in the future. |
|
First batch of builds landed in #70! 🥳 |
|
Interested parties here can work towards removing usage of CDTs that we haven't lifted to alma8 (and We discussed in the core-call today that we'll probably do a separate migrator for that as well, but the less it has to chew through, the better. :) Here's some searches to get you started (lots of X11, mesa, alsa etc. to be removed in both cases): The only CDTs that can stay (if the feedstock still requires it) should be the following: Lines 1 to 21 in d020455 |
|
I think there is a question about the CDT builds as part of the tk + freetype. Without them we edit: would -> may. I haven't done the full research to check that we do in fact get circular dependencies. |
We need to figure out which ones we need to keep vs ones we can build?
The text was updated successfully, but these errors were encountered: