Only override pacman-mirrors for Git for Windows

[dscho]

A really nice feature of the pacman mirrorlists is that you can specify multiple locations for package indexes and all of them will be used.

That means that we actually do not have to override anything in /etc/pacman.conf because we can just piggy-back our Bintray repositories via the pacman-mirrors package that provides the mirrorlist.* files.

All we have to do is to make sure that the package index is actually not called git-for-windows.db.tar.xz, but mingw32.db.tar.xz, mingw64.db.tar.xz and msys2.db.tar.xz, respectively.

[dscho]

@sschuberth I think that would be a much more light-handed way to handle the situation than to override pacman altogether, don't you think?

[sschuberth]

A really nice feature of the pacman mirrorlists is that you can specify multiple locations for package indexes and all of them will be used.

I was in fact looking for that feature being documented somewhere, but I was unable to find anything authoritative. In principle, it could be that pacman expects all servers within a single mirrorlist file to be full mirrors, just uses them to sort by connection speed, and only falls back to another mirror if a previous one is not reachable, but no if a specific package could not be found on the original server.

Do you have a link stating that pacman actually "merges" the package databases of all mirrors?

[sschuberth]

All we have to do is to make sure that the package index is actually not called git-for-windows.db.tar.xz, but mingw32.db.tar.xz, mingw64.db.tar.xz and msys2.db.tar.xz, respectively.

You're right in that it would be easier in terms of fewer initial changes that we need to do to the pacman(-mirror) packages. But we already did these changes. And as @t-b said, we should ensure that we're able to build all our required packages from source anyway. Finally, I believe upstream MSYS2 did not a good job at naming their repository sections and splitting between mingw32 and mingw64 (That should be done via $arch in the URL, or?).

[dscho]

Okay, your call. I am just reluctant to keep our pacman up-to-date (just have a look how fast MSYS2-packages' pacman/ history moves). I hope that you will take care of that?

[sschuberth]

I hope that you will take care of that?

I don't intend to :-) More seriously, by now we already have a bunch of changes against upstream. The addition of the git-for-windows config section is not the only one. If it was, I'd probably follow your suggestion.

[dscho]

I hope that you will take care of that?

I don't intend to :-)

Well, that leaves us between a rock and a hard place. You suggest changes that will be a real pain to maintain, and I am not willing to bear that pain myself. Instead, I suggested something much less heavy-handed that should allow us to give users access to our Pacman repositories but does not require us to update our own fork of the pacman package every couple of days, but you reject that.

More seriously, by now we already have a bunch of changes against upstream. The addition of the git-for-windows config section is not the only one. If it was, I'd probably follow your suggestion.

The idea is of course to get our changes upstream, but who knows how long that will take. The point is that we should decide upon a proper course of action. I know I won't have time (nor fun) keeping pacman up-to-date, so I want to steer clear from that direction. Unless you have a better solution that convinces me 😀

[sschuberth]

The idea is of course to get our changes upstream, but who knows how long that will take.

Exactly. But unless my config change is the only one against upstream, we would need to keep up with upstream all the time anyway. My goal of course is to also the get config change upstream. And I think there's a good chance getting that done, as it takes the burden off of upstream to maintain the mingw-git package.

[dscho]

But unless my config change is the only one against upstream, we would need to keep up with upstream all the time anyway.

No, not if we change only the pacman-mirrors package. That one is slow moving. Glacial, even.

My point stands: I will be very unhappy if I am the one to get stuck with keeping a forked pacman package up-to-date.

[sschuberth]

No, not if we change only the pacman-mirrors package. That one is slow moving. Glacial, even.

Yes, I understand. Again, my point is that that my config change is not the only one against the pacman package that we have compared to upstream. We currently have:

$ git log --oneline HEAD --not upstream/master -- pacman
45ad3cd pacman: Bump the pkgver
4936bf5 Move the git-for-windows package server URL to a mirrorlist file
7a7b0ed pacman: work around Git checkout with core.symlinks = false
f132193 Merge remote-tracking branch 'origin/master'
e7f38ad pacman: Bump the pkgver/rel via makepkg
d4c2420 pacman: Add missing makedepends to the PKGBUILD
7298f93 Fixup the MD5 for pacman.conf due to the recent changes
99afcae pacman.conf: Make use of $repo for git-for-windows
46b8737 Consolidate identical pacman.conf.{i686,x86_64} files into one
8c42369 Introduce the git-for-windows repository to pacman

Unless all of these are upstream we would need to keep up with the fast-moving pacman from upstream anyway.

How about this: I promise to try taking all of the above which are mine to upstream as quickly as possible, and if not possible, I'll drop them in favor of a different solution that does not require us to rebuild pacman.

[dscho]

The bumps of the pkgver do not at all need to be pushed upstream.

[dscho]

I promise to try taking all of the above which are mine to upstream as quickly as possible, and if not possible, I'll drop them in favor of a different solution that does not require us to rebuild pacman.

Okay, closing this ticket for now, then.