orphaned and unneeded packages

[jeremyd2019]

Orphaned packages (no longer in a repo):

$ pacman -Qmq
automake1.10
automake1.6
automake1.7
automake1.8
automake1.9
crypt
libcrypt
mingw-w64-i686-7zip
mingw-w64-i686-osslsigncode

(those last two I blame on the dropping of mingw32 from packages in msys2/MINGW-packages. @lazka maybe they could be reconsidered if they don't have too many deps, which they don't seem to)

Packages that were installed as dependencies but are not required by any installed packages:

$ pacman -Qtdq
glib2
icu
libatomic_ops
libgpgme
liblzo2
mingw-w64-i686-gettext-tools
mingw-w64-i686-glib2
mingw-w64-i686-jemalloc
mingw-w64-i686-libdeflate
mingw-w64-i686-libxml2
mingw-w64-i686-lzo2
mingw-w64-i686-pdcurses
mingw-w64-i686-rtmpdump
mingw-w64-i686-spdylay
perl-XML-Parser
tcl

I don't know if any of these are still needed (and should be marked as explicitly installed) or if they're left behind after updates made them no longer necessary.

[rimrul]

See also git-for-windows/git#5395

[dscho]

mingw-w64-i686-7zip

This is needed to build Portable Git and MinGit.

mingw-w64-i686-osslsigncode

This is needed to code-sign all the .exe files that are code-signed.

mingw-w64-i686-gettext-tools

This is needed for msgfmt, to compile Git's translated messages.

perl-XML-Parser

As far as I remember, this is needed by git svn, but see also git-for-windows/git#5405 (read: we may not need this for much longer anyway, besides, after v2.48.1 for i686 only MinGit will be released and that does not contain Perl let along git svn).

tcl

This is needed by gitk and Git GUI. Having said that, after v2.48.1 for i686 only MinGit will be released and that does not contain any interactive tools (except for those that are entangled with non-interactive tools).

[lazka]

(those last two I blame on the dropping of mingw32 from packages in msys2/MINGW-packages. @lazka maybe they could be reconsidered if they don't have too many deps, which they don't seem to)

sure, done

[jeremyd2019]

tcl

This is needed by gitk and Git GUI. Having said that, after v2.48.1 for i686 only MinGit will be released and that does not contain any interactive tools (except for those that are entangled with non-interactive tools).

tcl or mingw-w64-i686-tcl? (or both)?

Given the above, I'd recommend (after the next sync that updates the sync dbs so -7zip and -osslsigncode are no longer orphaned):

pacman -S --dbonly --asexplicit mingw-w64-i686-gettext-tools perl-XML-Parser tcl
pacman -Rns $(pacman -Qmq) $(pacman -Qtdq)

... oops,

:: removing libcrypt breaks dependency 'libcrypt' required by curl
:: removing libcrypt breaks dependency 'libcrypt' required by heimdal-libs
:: removing libcrypt breaks dependency 'libcrypt' required by libcurl
:: removing libcrypt breaks dependency 'libcrypt' required by libsasl
:: removing libcrypt breaks dependency 'libcrypt' required by openssh
:: removing libcrypt breaks dependency 'libcrypt' required by perl
:: removing libcrypt breaks dependency 'libcrypt' required by perl-XML-Parser

wasn't libcrypt replaced with libxcrypt?

[dscho]

tcl or mingw-w64-i686-tcl? (or both)?

Whoops, you're right, tcl can go, only mingw-w64-i686-tcl is needed (and mingw-w64-i686-tk).

Given the above, I'd recommend (after the next sync that updates the sync dbs so -7zip and -osslsigncode are no longer orphaned):

pacman -S --dbonly --asexplicit mingw-w64-i686-gettext-tools perl-XML-Parser tcl
pacman -Rns $(pacman -Qmq) $(pacman -Qtdq)

Sounds good.

... oops,

:: removing libcrypt breaks dependency 'libcrypt' required by curl
:: removing libcrypt breaks dependency 'libcrypt' required by heimdal-libs
:: removing libcrypt breaks dependency 'libcrypt' required by libcurl
:: removing libcrypt breaks dependency 'libcrypt' required by libsasl
:: removing libcrypt breaks dependency 'libcrypt' required by openssh
:: removing libcrypt breaks dependency 'libcrypt' required by perl
:: removing libcrypt breaks dependency 'libcrypt' required by perl-XML-Parser
wasn't libcrypt replaced with libxcrypt?

It's quite possible that I did not follow best practices there; The packages on the right side seem all to be ones of which Git for Windows builds custom packages.

At this stage, just before the last Git for Windows version that ships with i686 installers and Portable Gits, I do not want to put much work into this, though: Come Thursday 🤞we can stop caring about i686 variants of curl, and perl. We do probably need to still include openssh though... 😦

[jeremyd2019]

what about the check dlls action failure? I tried to figure it out, but the scripts involved were confusing me. I think at least one indicates that git-for-windows-provided i686 gnutls package needs to be rebuilt to link against the current msys-unistring-5.dll. The rest, I don't know.

[jeremyd2019]

what about the check dlls action failure? I tried to figure it out, but the scripts involved were confusing me. I think at least one indicates that git-for-windows-provided i686 gnutls package needs to be rebuilt to link against the current msys-unistring-5.dll. The rest, I don't know.

I saw git-for-windows/build-extra#591 last night. Too many repositories for me to keep track of 😉

... oops,
:: removing libcrypt breaks dependency 'libcrypt' required by curl
:: removing libcrypt breaks dependency 'libcrypt' required by heimdal-libs
:: removing libcrypt breaks dependency 'libcrypt' required by libcurl
:: removing libcrypt breaks dependency 'libcrypt' required by libsasl
:: removing libcrypt breaks dependency 'libcrypt' required by openssh
:: removing libcrypt breaks dependency 'libcrypt' required by perl
:: removing libcrypt breaks dependency 'libcrypt' required by perl-XML-Parser
wasn't libcrypt replaced with libxcrypt?

It's quite possible that I did not follow best practices there; The packages on the right side seem all to be ones of which Git for Windows builds custom packages.

libcrypt-devel was removed and replaced with libxcrypt-devel in July 2023, and libcrypt was dropped in October. I'll look at making a PR in the git-for-windows/MSYS2-packages fork to switch these packages to say they depend on libxcrypt.

[dscho]

I saw git-for-windows/build-extra#591 last night. Too many repositories for me to keep track of 😉

Yup, and for me it's even too many patches to keep track of, upstream Git is currently making my life hard.

wasn't libcrypt replaced with libxcrypt?

It's quite possible that I did not follow best practices there; The packages on the right side seem all to be ones of which Git for Windows builds custom packages.

libcrypt-devel was removed and replaced with libxcrypt-devel in July 2023, and libcrypt was dropped in October. I'll look at making a PR in the git-for-windows/MSYS2-packages fork to switch these packages to say they depend on libxcrypt.

Thank you.

It wouldn't be possible to mark libxcrypt as provides=('libcrypt'), would it?

[jeremyd2019]

The reason that wasn't done at the time was that libcrypt provided msys-crypt-0.dll while libxcrypt provides msys-crypt-2.dll. Both were kept for a time so that it wouldn't break the world (in the sort of way you seem to have noticed with msys-unistring-2 -> 5 in i686 😁) while packages were rebuilt. GfW's i686 packages of course missed the transition period due to the periodic-sync-nature of i686 updates. Hopefully git-for-windows/MSYS2-packages#218 results in everything there linking to msys-crypt-0.dll being updated (and if not, somebody's missing a depends on libcrypt).

[lazka]

(I just wanted to add that it wasn't my intention with the sync to make this much extra work this close to the git4win 32bit semi-EOL. In theory the sync could be ignored, no?)

[jeremyd2019]

Given the above, I'd recommend (after the next sync that updates the sync dbs so -7zip and -osslsigncode are no longer orphaned):

pacman -S --dbonly --asexplicit mingw-w64-i686-gettext-tools perl-XML-Parser tcl
pacman -Rns $(pacman -Qmq) $(pacman -Qtdq)

Make that

pacman -S --dbonly --asexplicit mingw-w64-i686-gettext-tools perl-XML-Parser
pacman -Rns $(pacman -Qmq) $(pacman -Qtdq)

After git-for-windows/MSYS2-packages#218. How is this done? The dbonly could be reasonably done as a PR against this repo, I guess, the local db is text so the changes will be obvious. Is there a need for some workflow to remove packages? (In that case it'd be better to inline the list explicitly rather than using $())

[jeremyd2019]

After git-for-windows/MSYS2-packages#218. How is this done? The dbonly could be reasonably done as a PR against this repo, I guess, the local db is text so the changes will be obvious. Is there a need for some workflow to remove packages? (In that case it'd be better to inline the list explicitly rather than using $())

#40 for consideration.

You'd probably need to do whatever needs doing to repo-remove the unneeded i686 packages (libsasl is blocking removing libcrypt at this point).

[dscho]

You'd probably need to do whatever needs doing to repo-remove the unneeded i686 packages (libsasl is blocking removing libcrypt at this point).

Indeed, and that repo-remove needs to have an effect on both the old Pacman repository on Azure Blobs as well as on the new one at pacman-repo. And the package files need to be git rmed from pacman-repo's tip, too.

My best idea for that would be to copy-edit the build-and-deploy workflow as well as pacman-helper.sh quick_add (or maybe rename and refactor quick_add so that it can perform both repo-add and repo-remove, then add a small quick_add adaptor function on top).

[jeremyd2019]

If you don't beat me to it, I'll try to look at that tomorrow. I've also got a fix for Cygwin to try to get submitted tomorrow too, since it sounds like 3.6.0 is expected to be released in a couple of weeks.

[dscho]

I daresay that this has been addressed via #42 and #43. Thank you so much @jeremyd2019!