On Thu, Feb 16, 2006 at 01:10:38PM +0100, Loic Dachary wrote: > Matthias Klose writes: > > reopen 339237 > > thanks
> > > Changes: > > > openalpp-cvs (20060217-1) unstable; urgency=low > > > . > > > * upstream sync (closes: #339237) > > that's pretty much not a fix. even no reply on Steve's question in the > > bug report. please comment. > I overlooked the question. Sorry about that and thanks for the > reminder. > Regarding the name, openalpp-cvs reflects the fact that the > upstream do not do formal releases. However, the software has had a stable > API during the past two years. My hunch is that it's not likely to change > in the near future (library issued from research, fullfilling the needs > and not evolving much). > It would probably be appropriate to suffix it with 0 and do an > independent library versioning to avoid ABI problems. > I'd be tempted to leave the name as it is. You can't leave the name as it is. If you can't support a stable ABI, you can't have a shared library shipped in a stable release. Given that the name "libopenalpp-cvs" was already used in sarge, you must either change the binary package name or drop the shared library to have openalpp-cvs in etch. > The binary was recompiled on the latest unstable and since the upstream > version changed I understood it was not necessary to prepend the c2a. > Was I wrong ? New upstream versions are only relevant if they include soname changes. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
