syncpackage and (especially) the new auto-sync tool I'm writing to
replace 'sync-source.py -a' could make good use of this as well, but
only if it's done with the right semantics. The reason is a little
complex, so bear with me a moment.
When we sync a source package from Debian to Ubuntu, we want to make
sure that it does not accidentally override Ubuntu modifications. (It's
OK to do that deliberately, but a developer has to check this.) We do
this by checking for an "ubuntu" substring in the version number, and if
it's present then we require a force option. All well and good so far.
However, there's a wart. Consider the case where we have two source
packages like this, generating a different set of binary packages each:
libfoo 1.0-1ubuntu1
-> libfoo1 1.0-1ubuntu1
-> libfoo-dev 1.0-1ubuntu1
foo 1.0-1
-> foo 1.0-1
Upstream decides to merge the library and the program that use it into a
single release, so the next version we sync from Debian is:
foo 1.1-1
-> libfoo1 1.1-1
-> libfoo-dev 1.1-1
-> foo 1.1-1
A simple source check wouldn't spot the problem here, but if we check
the binaries too then we can see that we may be discarding some Ubuntu
changes, and that this needs a manual check in advance of syncing the
source.
Now, sync-source.py handles this case by executing a gruesome pile of
SQL which roughly amounts to Archive.getPublishedBinaries, checking the
Binary field of the .dsc it's syncing to see which binaries it produces,
and checking that each of those binaries has a suitable version in the
archive at the moment. This mostly works, and I believe we can
replicate that with Archive.getPublishedBinaries right now.
However, there's a problem. In the example above, what happens if foo
1.1-1 fails to build? Perhaps Debian fixes that and then we want to
sync their fix, which is foo 1.1-2. However, the published binaries in
the archive are still 1.0-1ubuntu1, so even though we've already taken
an explicit decision to override those Ubuntu modifications we're now
going to have to do so again. (There's also another rarer problem
related to packages where the binary version isn't the same as the
source version; I've seen one source package that doesn't itself have
any Ubuntu modifications but which builds binary packages with an ubuntu
version substring.)
This is a periodic annoyance for me as the guy running auto-syncs, since
I have to stop and figure out what's going on. I'd like to make the
tools deal with it for me. I believe that the correct algorithm would
be to look up the source package that owns the binary package, by which
I mean not necessarily the one linked from the most recent BPPH, but the
most recent source package that wants to build that binary package (per
SPR.dsc_binaries or similar), and then I could simply check its version
to see if I like it.
It would probably be simplest to have a way to return all source
packages that want to build a given binary, and then I can look through
those to see which ones I care about. I think this feels natural enough
in the LP API because lookups for source and binary publications also
return collections. How about
Archive.getPublishedSources(binary_name=...), which you could then limit
by series, binary version, etc. as required? Would that work for
everyone?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/597041
Title:
No way to get from binary package to source package
To manage notifications about this bug go to:
https://bugs.launchpad.net/launchpad/+bug/597041/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
