On Thu, Nov 15, 2007 at 07:41:26PM +0100, Cyril Brulebois wrote: > Matt Zimmerman <[EMAIL PROTECTED]> (15/11/2007): > > "The run-time shared library needs to be placed in a package whose > > name changes whenever the shared object version changes." > > > > If you do not pay attention to this issue, then when the soname of > > this library changes, you will break upgrades for all of its users. > > And? The soname version isn't present in the package name (rather soname > version+1). I don't see what the policy violation is. As you quoted, the > name as to change when the shared object version changes. And such a > change didn't seem to have happened. What's the actual breakage?
This isn't a policy violation if the package was misnamed this way in the first place, but it is awfully confusing and will be even more so if the soname version is ever incremented to 1. I'm surprised this made it into the archive in its current form. Are you maintaining this package now? The maintainer is listed as Mathias Palm <[EMAIL PROTECTED]> in the control file. > > So regardless of how severe you think this issue is with regard to the > > requirements of Debian policy, please do fix it. > > The only issue I can see here is a cosmetic one, and gratuitously > renaming packages sounds a bad idea to me. A whopping one other package depends on libvformat1, so I don't think there would be any significant disruption from this. As you rightly point out, policy doesn't enforce a precise naming scheme, and you could probably name the package frobnicator3.14159 if you wanted, but it's common (and sensible) practice to name it after the library inside. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
