[arch-projects] [dbscripts] [GIT] Official repo DB scripts branch verify-update-plus-rebuild created. 20180603-17-g77c7269
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "Official repo DB scripts". The branch, verify-update-plus-rebuild has been created at 77c72694e608decd63978f3ae6d941487476ef98 (commit) - Log ----------------------------------------------------------------- commit 77c72694e608decd63978f3ae6d941487476ef98 Author: Eli Schwartz <eschwartz@archlinux.org> Date: Sun Dec 2 12:07:05 2018 -0500 db-move: also block moving package from staging to extra without handling testing Don't allow anomalous testing packages floating around after a rebuild which are older than stable. commit aeeaac2e9979c8bf51f1e3401cc3c3f94fba7571 Author: Eli Schwartz <eschwartz@archlinux.org> Date: Sun Dec 2 11:28:20 2018 -0500 db-update: die when trying to update a package without updating a pending rebuild A semi-common pattern is for one maintainer to stage a rebuild of a package due to e.g. cascading repository-wide python/boost/whatever rebuilds, and then for the original maintainer of the package to not notice and update the package in the stable repo, leaving an out of date rebuild in staging or testing. Then the the out of date package gets moved and ends up breaking things, possibly via a package downgrade, possibly via breaking compatibility with a much more targeted rebuild uploaded all at once. Ultimately, Things Happen™ and the repository hierarchy gets broken. Prevent this by enforcing for all packages that exist in multiple levels of the repo: staging -> testing -> stable That updates to one must come with an update to all the others. commit 4a0f58b1eb729755bc2e5c2f68968c41bb859b76 Author: Eli Schwartz <eschwartz@archlinux.org> Date: Sun Dec 2 12:28:36 2018 -0500 testing2x: be more generic and accept multiple testing repos Currently multilib is a second-class citizen the way it is lumped into community, and dbscripts cannot even keep track of whether it constitutes a testing repo. Teach config to track both testing and staging repos just like the stable ones, and teach testing2x to search through TESTING_REPOS to determine which one it is operating on. ----------------------------------------------------------------------- hooks/post-receive -- Official repo DB scripts
participants (1)
-
eschwartz@archlinux.org