On Sat, Jan 11, 2020 at 09:57:42AM -0500, Dave Reisner wrote:
On Fri, Jan 10, 2020, 16:43 Christian Rebischke via arch-dev-public <[1]arch-dev-public@archlinux.org> wrote:
Hi everybody, I would like to propose that we create todos for rebuilds of language specific packages. We had two major rebuilds in the last months: python3.8 and ruby2.7. Can we agree that we create a todo before such rebuilds? The advantages outweigh the disadvantages. We would gain:
Hi, I'm not sure I understand. Can you clearly state the problems we've encountered due to not doing this? What downsides do you see to your proposal? Can you think of any alternative solutions?
Hi Dave, I am sorry. Looks like my actual proposal was a little bit unclear and the whole discussion drifted to automation. This has been never my intention. I have no problem with the actual rebuild process and I don't care if this happens manually or automated. Actually I didn't want to point out specific package problems, but you asked me, here they are. My problem is that several packages dependending on ruby broke due to the ruby2.7 rebuild: * puppet5 broke due to missing ruby-sync in ruby2.7[1] * puppet broke due to missing ruby-sync in ruby2.7[2] * gitlab has problems with its API after ruby2.7 rebuild[3] Furthermore multiple packages are throwing deprecation warnings now: * gitlab[4] * puppet5/puppet [1][2] * vagrant has issues with the ruby2.7 rebuild[5] Big thanks to Anatol for reporting several of these issues upstream and fixing packages. I really appreciate his work. The rebuild process itself is totally fine for me. I just wanted to point out, that we should have a defined process for rebuilds. Either in form of todos or in form of more communication on a-d-p like "We are going to push all ruby rebuilds from [testing] to [community] on date X. Make sure it's tested, if you encounter any problems, speak with A, B or C or response directly in this thread".
* More people help rebuilding the packages.
Solving the wrong problem, IMO. This is largely toil and should be automated away. Foutrelis already has such a system that we've used for rebuilds in the past. We could/should instead work towards making this more generally available on the build machines.
I agree.
* Every maintainer gets informed about the rebuild.
As a maintainer, I don't care that you're rebuilding my package to keep up with library changes. Rather, I'm thankful to whomever did this for me. Why would a language rebuild differ from any other soname bump?
I mostly agree, still would be nice to get a notification.
* Maintainers have the possibility to test the packages.
Why is this not currently possible? Couldn't we just use testing prior to pushing out to the repos (something we've done in the past and continue to do)? What about packages which aren't using the lowlevel API and are simply interpreted code. Those don't get rebuilt, but they're potentially impacted by the language version bump. They'll never be called out on a rebuild lost because we generate those based on ELF dependencies. dR
[testing] has been used and I wanted to test my packages, but the push from [testing] to [community] happened before my scheduled date for this. I just say that it would be nice if we have a defined process for rebuilds with specifying a deadline for tests. My hope is that this mail makes my intention clear now. The "proposal" is just a spawn point for a discussion around a defined process for rebuilds to prevent not working packages in the future. Arch Linux is known for bleeding edge software _and_ stability, let's keep it this way. [1] https://bugs.archlinux.org/task/65106 [2] https://bugs.archlinux.org/task/65107 [3] https://bugs.archlinux.org/task/65097 [4] https://bugs.archlinux.org/task/64887#comment185125 [5] https://github.com/hashicorp/vagrant/issues/11290