On Fri, Feb 15, 2013 at 08:09:45PM -0500, Phillip Susi wrote: > It looks like upstream is improperly versioning their libraries so the > package violates debian policy. They have a major version of 835 > which has now gone to 838 in experimental, and then 84 in the new > version in Ubuntu raring. I think this means we need an epoch and > - -debian0 ABI version.
No, no, no, no, no, no, no, no, no. This is a seriously mangled version of the state of affairs. There's nothing wrong with upstream going from 835/838 to 84; SONAMEs need to be unique per ABI but they don't need to follow any particular prescription for how they're changed. Neither an epoch nor a Debian-specific ABI is necessary, and certainly the latter would be actively harmful. What actually happened here is as follows: * Some time back, Daniel got fed up with the NEW processing treadmill for SONAME changes in ntfs-3g and folded the separate library package into the primary ntfs-3g package, since it had no reverse-dependencies. * I changed testdisk in Ubuntu to build against ntfs-3g rather than the old and deprecated libntfs. At the time my focus was getting rid of old libraries, and it hadn't occurred to me that this would interact interestingly with this change. * On the next upstream ABI change, testdisk broke because it had a DT_NEEDED entry for the old libntfs-3g SONAME, and no packaging metadata could have warned users about it or automatically prevented the change from reaching testing. I suggest a compromise which would preserve the convenience of avoiding NEW processing while having more accurate metadata: have ntfs-3g Provides: libntfs-3gSOVER (substituted as appropriate), and make shlibdeps use libntfs-3gSOVER as the generated dependency rather than ntfs-3g. That way, we'll be able to tell automatically that reverse-dependencies will be broken. You might just need to take a little care to avoid ntfs-3g having a self-dependency via the new virtual package. (It would be better to have the library package separate again, because that way the old and new libraries could be coinstallable which would make upgrades smoother. However, since testdisk is a non-Essential leaf package, it isn't completely horrible for it to break during upgrades, just unsightly; and I do understand the convenience argument.) Thanks, -- Colin Watson [cjwat...@ubuntu.com] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
