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

Doing one more sync #2

Open
lazka opened this issue Jun 14, 2024 · 5 comments
Open

Doing one more sync #2

lazka opened this issue Jun 14, 2024 · 5 comments

Comments

@lazka
Copy link

lazka commented Jun 14, 2024

@jeremyd2019 just wondering, would you mind if I do one more sync of this into the main repo, similar to what we did in 2021? I don't know when I find time though.

That would allow us to get rid of old signing keys over time.

@jeremyd2019
Copy link
Owner

If you like... I do test updating from the last released i686 installer from 2021. Some things to think about:

  1. I don't ever remove packages from this repo... due to how it's used, that would be counter-productive because pacman would just fall back to getting the package from the original i686 msys2 repo. So when you sync, you probably also want to remove packages that are not in the x86_64 repo. (Should be easy enough to figure out, minor adjustment to what https://github.com/msys2/pacdb/blob/mater/examples/msys32.py does, use pkg.name instead of str(pkg) and reverse the set difference).
  2. If you then want to make an updated installer, that could be difficult because somebody removed the i686 qt installer framework. In my fork I just dropped that installer, I only ever use the sfx anyway. Probably would be difficult anyway because msys2-installer doesn't have any of the bitness stuff left in it (I reverted that in my fork). https://github.com/jeremyd2019/msys2-installer. Just manually bootstrapping a root with pacman and making tars/sfx would probably work.
  3. I don't know what you'd want to do about msys2-runtime. What I ended up doing is installing msys2-runtime-3.3 package as part of the installer building. That may not be what you want to do, and doesn't help people updating know that there's a newer runtime they could use. I was thinking about maybe making msys2-runtime-3.3 replace msys2-runtime on i686, but was never worth the effort to figure out if that would work.

@lazka
Copy link
Author

lazka commented Jun 14, 2024

Thanks for your thoughts. I'll give it a try then when I feel motivated.

  1. yeah, last time I think I used msys2-web and pointed it to the i686 repo to figure out what to add/remove.

  2. We already dropped the i686 gui installer in 2021, so not a problem.

  3. yeah, I though about that too, or adjust msys2-runtime-3.3 to build msys2-runtime in case of i686, so it's less of a special case.

That would allow us to get rid of old signing keys over time.

I was referring to msys2/MSYS2-keyring#45 btw

@jeremyd2019
Copy link
Owner

ok, I was thinking "getting rid of old signing keys" meant needing to have a new installer with a newer msys2-keyring package in it, that knew about the "new" signing keys.

@jeremyd2019
Copy link
Owner

To be honest, I expected that you would be removing the msys/i686 directory from repo.msys2.org (and thus the mirrors) at any time, so a while back I downloaded all packages from there that did not have versions here already, and uploaded them here and added them to the sync db. So the usage could have changed to remove the msys entry from pacman.conf and replace it with the entry for this repo.

@lazka
Copy link
Author

lazka commented Jun 15, 2024

Hm, that's of course also an option, to get rid of it alltogether. Maybe do a brownout to see if anyone complains.

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