Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migrate to xorg-xorgproto #2

Merged
merged 2 commits into from
Oct 3, 2024
Merged

Migrate to xorg-xorgproto #2

merged 2 commits into from
Oct 3, 2024

Conversation

ehfd
Copy link
Member

@ehfd ehfd commented Oct 3, 2024

Checklist

  • Used a personal fork of the feedstock to propose changes
  • Bumped the build number (if the version is unchanged)
  • Reset the build number to 0 (if the version changed)
  • Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
  • Ensured the license file is being packaged.

@ehfd
Copy link
Member Author

ehfd commented Oct 3, 2024

@conda-forge-admin, please rerender

@conda-forge-admin
Copy link
Contributor

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.

@ehfd ehfd merged commit 6104776 into conda-forge:main Oct 3, 2024
5 checks passed
@hmaarrfk
Copy link

hmaarrfk commented Oct 3, 2024

I wonder if we can get this transition complete by just adding a little linter rule

        - xorg-xextproto
        - xorg-glproto
        - xorg-xorgproto

you can add the old protos to
https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/main/recipe/linter_hints/hints.toml

@ehfd
Copy link
Member Author

ehfd commented Oct 3, 2024

@hmaarrfk I think so, but the old protos aren't archived yet. When some kind of conda-forge wide migration for this happens.

@hmaarrfk
Copy link

hmaarrfk commented Oct 3, 2024

you can launch it, but what is the real harm? a conflict clobber of header files. that is pretty minor IMO.

edit: conflict -> clobber

@ehfd
Copy link
Member Author

ehfd commented Oct 3, 2024

Anyways, it's a bit early because I'm not sure all of the X11 packages are done migrating.

@hmaarrfk
Copy link

hmaarrfk commented Oct 3, 2024

Anyways, it's a bit early because I'm not sure all of the X11 packages are done migrating.

why i thought xorg-xorgproto was a superset of all packages.

just remind people (yourself, myself, and pkwg) to depend on that.

@ehfd
Copy link
Member Author

ehfd commented Oct 3, 2024

why i thought xorg-xorgproto was a superset of all packages.

I am just cautious because this can lead to failures downstream. I had an experience where colliding headers that were installed together through distinct dependencies failed conda-build.

@ehfd
Copy link
Member Author

ehfd commented Oct 3, 2024

I will reference @pkgw for the final decision on this.

@ehfd
Copy link
Member Author

ehfd commented Oct 15, 2024

@hmaarrfk

I wonder if we can get this transition complete by just adding a little linter rule

Can this be done as a regex xorg-[^(?!xorg$)]proto? Don't really know how many legacy proto packages exist.

@pkgw
Copy link

pkgw commented Oct 15, 2024

I believe there are about 33 legacy proto packages, based on:

https://www.x.org/releases/individual/proto/

Everything except xcb-proto is all merged into xorg-xorgproto now. It's also worth mentioning that the old proto packages are no longer getting updated, so this migration is necessary. There was a case where a library wouldn't build (I think it was libxinput) because it needed newer prototypes that were provided in the xorgproto version of the input prototypes, but not in the inputproto version.

Another factor: before, because there were so many proto packages I added them as run dependencies of the xorg-libx* library packages, since it would be a big pain to have to remember "OK, since I'm building against xorg-libxaw3d, I need to also depend on xorg-inputproto, xorg-xproto, xorg-fixproto, ....".

Now that there's basically only one package, I got rid of those run dependencies. So, packages that have host deps on xorg-libx* libraries will probably need to add a host dep on xorg-xorgproto as well. This is another thing that it would be nice to have a linter/migration check for.

@pkgw
Copy link

pkgw commented Oct 15, 2024

Oh, and, at this point I believe that the core xorg-* packages are all done migrating to the new UCRT Windows runtime + xorgproto standard. I haven't checked the migration status for a while but I've stopped seeing PRs to those packages, and I did a pass over the migration status a couple of weeks ago and there weren't any xorg-* packages left in the queue.

@ehfd
Copy link
Member Author

ehfd commented Oct 15, 2024

I compiled relevant information to conda-forge/staged-recipes#26241 @pkgw

@ehfd
Copy link
Member Author

ehfd commented Oct 16, 2024

@h-vetinari
Copy link
Member

I think this needs to be fixed so that it points to host: libgl-devel

Could you please open a PR to https://github.com/conda-forge/conda-forge.github.io?

@ehfd
Copy link
Member Author

ehfd commented Oct 16, 2024

Opened in conda-forge/conda-forge.github.io#2334 but the linter hints for the relevant Mesa/OpenGL CDTs should also be added.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants