On Fri, 2007-02-23 at 19:13:09 +0100, Florian Weimer wrote: > * Guillem Jover: > > The resulting .changes will get a field like this: > > > > Source: bacula (1.38.11-7) > > > > which can be used to track back from which source this binary > > originated. > > Yeah, but this only helps if you've got a source version to compare > to. You could derive that from a binary version if you've got the > corresponding Package entry, but this information might not be > available anymore when you need it.
Sorry if I was unclear, but this field with that information is present in the binary packages and then exposed through the Packages file. It's even on dpkg's status file. > Furthermore, it's not particularly useful to address the > inconsistencies added by binNMUs when there are other problems. Some > binary packages have different version numbering schemes on different > architectures, or they are built from different source packages. The only current problem I see from the binNMU implementation in dpkg is that packages that have a different source version than the one for the binary packages will not receive a proper binNMU version as those package generate the version manually, neither the binary:Version will be correct, as we'd have to introduce a binary:<binpkg>:Version or similar to be able to deal with those. Given the small amount of packages doing this I decided to implement something that'd work for almost all packages except for the few odd cases, that would be problematic anyway now. This could be fixed in the future if there's a pressing need. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
