Consider dropping a couple of packages from the git-sdk-* repositories
#5395
Comments
I think we're using
Getting rid of old autoconf/automake versions should be fine.
PCRE1. We really don't need to keep this around.
We've got rid of amd64 fortran years ago and don't need i686 fortran either. git-for-windows/git-sdk-64@3764e6c
doesn't pacman depend on this? |
Right, we did use it at some point early on, I think, but then never dropped it from the
Note, though: $ pactree -r mingw-w64-x86_64-pcre
mingw-w64-x86_64-pcre
└─mingw-w64-x86_64-odt2txt
Great find!
No, it does not: $ pactree -r libgpgme
libgpgme
|
We could update that patch to use PCRE2. That reminds me, |
I guess that should work!
Ouch, you're right. I guess we'd have to find an alternative (or ask Devin to transpile it to C or Rust 😉) |
I have no clue who Devin is. If you're talking about the If you're talking about the |
Sorry, I had misspelled the name. It was a joke, I was referring to https://devin.ai/ :-) |
The
git-sdk-*repositories hold fully-populated MSYS2 setups (with a couple of packages drawn from Git for Windows' rather than MSYS2's Pacman repositories). They are kept up to date by thesyncworkflows that update the Pacman packages and commit the result.So what decided which packages are installed in those MSYS2 setups? The principal idea was that a regular Git for Windows release process should not need to install any additional packages; If it does, that's a bug. It was designed this way so that it is easy to "time-travel" to the point in time when a specific Git for Windows version was built, to be able to build security fix releases from that very point; This ensures that users who had the preceding version installed can upgrade to the security fix release with minimal risk of regressions.
And what about packages that are not required for building
mingw-w64-gitnor for any other part of releasing Git for Windows' installers, portable Gits, archives, NuGet packages and MinGits?Today, I had the opportunity to have a closer look. Specifically, I looked at the difference between the packages recorded in
/etc/package-versions.txtand the packages actually installed ingit-sdk-64. Concretely, I looked at the output of this lengthy command-line:Full output
I analyzed these manually and sorted them into the following categories:
Can probably be dropped
Are not strictly needed, but would be good to keep
In particular the autoconf and gcc stuff is required to build other packages than
mingw-w64-git, i.e. for builds that happen more frequently than releasing Git for Windows versions. It would be good to avoid having to install them every time.Also includes Python and the GNU debugger, but not Ruby (because that is needed to run AsciiDoctor, which is needed to build
mingw-w64-git-doc-*).Full list
Must keep
These are either needed to build
mingw-w64-gitor to keep the Git SDK Bash running smoothly.Full list
I likely made a couple of mistakes, so take that categorization with a grain of salt and ensure to test a
git-artifactsbuild!Speaking of
git-artifactsbuild: We probably want to make sure that themakepkg-mingwcall does not pass the-sflag, which would also make for a fine opportunity to migrate thebuild-mingw-w64-gitcode frombuild-extra'splease.shtogit-for-windows-automation, where it would find a more natural habitat.The text was updated successfully, but these errors were encountered: