[arch-projects] [dbscripts] [GIT] Official repo DB scripts branch master updated. 20180603-18-gd5970df

[eschwartz at archlinux.org]

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, master has been updated
       via  d5970df3a7051b7ceb5d69a345c763e9b5ed8052 (commit)
       via  8804e63f4414fdeef7f677c8b87a7acda052fd64 (commit)
       via  863818f2b2bcd00660299c5e609e5cf31d5213d0 (commit)
      from  948a181f5f09ca1cc03d450081f296222ca26d2f (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit d5970df3a7051b7ceb5d69a345c763e9b5ed8052
Author: Eli Schwartz <eschwartz at 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 8804e63f4414fdeef7f677c8b87a7acda052fd64
Author: Eli Schwartz <eschwartz at 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 863818f2b2bcd00660299c5e609e5cf31d5213d0
Author: Eli Schwartz <eschwartz at 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.

-----------------------------------------------------------------------

Summary of changes:
 config                     |  3 ++-
 config.local.svn-community |  3 ++-
 config.local.svn-packages  |  3 ++-
 db-functions               | 25 +++++++++++++++++++++++++
 db-move                    |  9 +++++++++
 db-update                  |  3 +++
 test/cases/db-move.bats    | 14 ++++++++++++++
 test/cases/db-update.bats  | 27 +++++++++++++++++++++++++++
 test/lib/common.bash       |  5 +++--
 testing2x                  | 26 ++++++++++++++++----------
 10 files changed, 103 insertions(+), 15 deletions(-)


hooks/post-receive
-- 
Official repo DB scripts