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

Remove unwanted /mingw32/ and /mingw64/ #27

Open
dscho opened this issue Nov 13, 2024 · 2 comments
Open

Remove unwanted /mingw32/ and /mingw64/ #27

dscho opened this issue Nov 13, 2024 · 2 comments

Comments

@dscho
Copy link
Member

dscho commented Nov 13, 2024

I just noticed that there is a non-empty /mingw64/ directory in HEAD; This is undesirable, but instead of simply deleting it, I'd like to use the opportunity to figure out how it came into being (so that it won't just simply come back after deleting it).

@rimrul
Copy link
Member

rimrul commented Nov 13, 2024

It looks like those slipped through the cracks of 5f8de1d (and the mingw32 equivalent). Some of those reasons seem obvious (`git extra used to not have a package prefix, ruby gems), but some are less obvious.

@dscho
Copy link
Member Author

dscho commented Nov 14, 2024

It looks like those slipped through the cracks of 5f8de1d (and the mingw32 equivalent). Some of those reasons seem obvious (`git extra used to not have a package prefix, ruby gems), but some are less obvious.

Aha! Yes, pacman -R would have missed those because:

  • I specifically retained some obsolete OpenSSL/libidn2 files (to allow an orderly upgrade to a newer versions that produce DLLs with different names, which would have broken git fetch and curl in the CI builds). However, I thought I had dropped these files in git-for-windows/build-extra@27f8403. I guess I should have checked... they're still there, even in git-sdk-64 and git-sdk-32...
  • The way I had installed asciidoctor with the extensions that Git still required back then was really hacky: calling gem install in the pre_install function, and of course I had not thought of adding a corresponding post_remove function 🤦

Since we no longer install those obsolete packages, I'm confident that they wouldn't come back just like that.

The best way to address this ticket that I can think of would be via yet another few lines in git-extra's post-install function.

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

No branches or pull requests

2 participants