[26483] in Source-Commits
Re: /svn/athena r25586 - trunk/debathena/scripts/build-server/build-all
daemon@ATHENA.MIT.EDU (Jonathan Reed)
Thu Jun 28 18:41:31 2012
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Jonathan Reed <jdreed@MIT.EDU>
In-Reply-To: <alpine.GSO.1.10.1206281739490.18441@multics.mit.edu>
Date: Thu, 28 Jun 2012 18:41:28 -0400
Cc: source-commits@MIT.EDU
Message-Id: <E9BDD4FD-5EDE-4892-8E31-5E61C632C048@MIT.EDU>
To: Benjamin Kaduk <kaduk@MIT.EDU>
Content-Transfer-Encoding: 8bit
On Jun 28, 2012, at 5:40 PM, Benjamin Kaduk wrote:
> On Thu, 28 Jun 2012, Jonathan D Reed wrote:
>
>> Author: jdreed
>> Date: 2012-06-28 12:51:08 -0400 (Thu, 28 Jun 2012)
>> New Revision: 25586
>>
>> Modified:
>> trunk/debathena/scripts/build-server/build-all/do-build
>> Log:
>> Support -staging repository (Trac: #966)
>>
>> Modified: trunk/debathena/scripts/build-server/build-all/do-build
>> ===================================================================
>> --- trunk/debathena/scripts/build-server/build-all/do-build 2012-06-28 12:58:05 UTC (rev 25585)
>> +++ trunk/debathena/scripts/build-server/build-all/do-build 2012-06-28 16:51:08 UTC (rev 25586)
>> @@ -6,7 +6,7 @@
>> psuite=$4
>> : ${DEBATHENA_APT=/mit/debathena/apt}
>> : ${DEBATHENA_BUILD_AREA=/afs/sipb.mit.edu/project/debathena/packages}
>> -: ${DEBATHENA_RELEASE=-development}
>> +: ${DEBATHENA_RELEASE=-staging}
>> export DEBATHENA_RELEASE
>> . /mit/debathena/bin/debian-versions.sh
>> tag=$(gettag $suite)
>> @@ -33,7 +33,7 @@
>> trap - EXIT
>> exit
>> fi
>> -for suffix in "" -proposed -development; do
>> +for suffix in "" -proposed -development -staging; do
>> vv=$(zcat ${DEBATHENA_APT}/dists/$psuite$suffix/*/source/Sources.gz | dpkg-awk -f - "Package:^$package\$" -- Version | sed -n 's/Version: // p')
>> if [ -n "$vv" ]; then
>> version="$vv"
>
> I am only mostly convinced I understand what this loop is doing, but ACK.
It's "for each of the repos, go look for source package versions, and accept the last found version of the package". Which, now that I think about it, is maybe not what we want. It's worked in the past, because the version numbers could only increase going from production to proposed to development. Since it's looking at psuite, this will work if we're diligent about clearing out -staging after something has been released. I wonder if instead we want some sort of "dpkg --compare-versions" invocation here, and we want to always accept the highest numbered version of a package? (which is what had been happening in the past anyway).
I'm not going to back out the change, since it doesn't break anything, merely introduces yet another point where poor housekeeping on our part can lead to repo version skew later. Which is part of what we were trying to avoid by using -staging instead of -development.
Thoughts?
-Jon
