[26485] in Source-Commits
Re: /svn/athena r25586 -
daemon@ATHENA.MIT.EDU (Benjamin Kaduk)
Thu Jun 28 20:04:00 2012
Date: Thu, 28 Jun 2012 20:03:57 -0400 (EDT)
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: Jonathan Reed <jdreed@MIT.EDU>
cc: source-commits@MIT.EDU
In-Reply-To: <E9BDD4FD-5EDE-4892-8E31-5E61C632C048@MIT.EDU>
Message-ID: <alpine.GSO.1.10.1206281949570.18441@multics.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
On Thu, 28 Jun 2012, Jonathan Reed wrote:
>
> 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
Right, that's what it looks like.
> about it, is maybe not what we want. It's worked in the past, because
Hence my confusion.
> the version numbers could only increase going from production to
> proposed to development. Since it's looking at psuite, this will work
Right. (That's still the case, is it not?)
> if we're diligent about clearing out -staging after something has been
> released. I wonder if instead we want some sort of "dpkg
Hmm, psuite, right. I'm not sure I follow the bit about needing to clear
out -staging after release, though.
> --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?
It does kind of seem like dpkg --compare-versions is the "right" thing to
do, though I'm not sure I've pinned down exactly why. But on the other
hand, if the --compare-versions would give something different than the
current code, we messed up somewhere. So I guess it could be partly a
diagnostic as well as a correctness thing.
On the other hand, it looks like the following code to generate the dsc
(if it does not already exist) relies on the version we're going for
existing in the repo for psuite. I feel like this could get us into
trouble if we start getting too fancy with version comparisons?
I don't know that I see an urgent need to change things, though this code
could probably be rewritten completely in a much better fashion.
-Ben
