On Sun, Mar 14, 2010 at 9:45 PM, Michael Hudson <[email protected]> wrote: > Jonathan Lange wrote: >> Hello, >> ... >> >> I'd like to upgrade zope.testing and take advantage of their better >> subunit support, but that requires upgrading subunit too. >> >> We currently maintain subunit as a sourcecode dependency. We manage it >> in the branch lp:~launchpad-pqm/subunit/trunk. That branch is a >> KnitPackRepository. subunit trunk is a 2a repository. >> >> If I naively change sourcedeps.conf like so: >> @@ -12,7 +12,7 @@ >> -subunit lp:~launchpad-pqm/subunit/trunk;revno=61 >> +subunit lp:~subunit/subunit/trunk;revno=120 >> >> I get incompatible repository errors. >> >> subunit is not a Python package. It's built with autotools, and thus >> making an egg for it is beyond my ken and maybe inappropriate. >> >> Which leaves me with a bunch of questions: >> >> 1. Changing sourcedeps.conf to point to a branch that's not managed by >> our PQM is OK, isn't it? After all, we still have to pass the tests to >> change the revno of the branch, so we aren't losing any safety afaict. > > As Max said, we are losing some safety. Not sure how much or how much > we care. >
I think we don't care. >> 2. If I changed update-sourcecode to just do a full remirror if the >> repository formats are incompatible, would we then encounter problems >> when we rolled out to production? > > Not sure. > >> 2a. How would I find that out without asking the list? > > Reading > https://wiki.canonical.com/InformationInfrastructure/OSA/LaunchpadRollout > might provide some clues (I haven't read all of it, tbh) > Eek! >> 3. Should we instead use buildout? >> >> 3a. If so, how on earth do I package subunit so that it can be used >> with buildout? Bear in mind this is something I doing in my personal >> time, so if it's not easy or the fun kind of hard, I'm not going to do >> it. > > Given the nature of subunit, I think Rob's suggestion of using a deb for > it makes some sense. Although the lack of hardy packages is obviously a > blocker. > Thanks to you, Rob & Max for the help. Sadly, I think I'm still blocked. I think subunit is relatively fast-moving compared to our other dependencies, and I don't think that .deb packaging is the best way to deal with that. In general, I don't really understand why one package should be maintained in buildout and another as an Ubuntu dependency. Further, I don't actually know how to switch it to use Ubuntu packages, and am just as unclear on what impact that would have on the buildslaves & prod environments as I am about changing update-sourcecode.py. cheers, jml _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
