[arch-dev-public] Todos for language specific rebuilds
Chris.Rebischke at archlinux.org
Mon Jan 13 17:28:27 UTC 2020
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
> <arch-dev-public at archlinux.org> wrote:
> Hi everybody,
> I would like to propose that we create todos for rebuilds of
> 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:
> 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?
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
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
* puppet broke due to missing ruby-sync in ruby2.7
* gitlab has problems with its API after ruby2.7 rebuild
Furthermore multiple packages are throwing deprecation warnings now:
* puppet5/puppet 
* vagrant has issues with the ruby2.7 rebuild
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.
> * 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
> 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.
[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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the arch-dev-public