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
signature.asc
Description: PGP signature