Il giorno mer, 16/07/2008 alle 19.37 -0500, William Pitcock ha scritto: > On Thu, 2008-07-17 at 00:57 +0200, Francesco Namuri wrote: > > Il giorno mer, 16/07/2008 alle 17.46 -0500, William Pitcock ha scritto: > > > Hi, > > > > > > On Wed, 2008-07-16 at 22:59 +0200, Francesco Namuri wrote: > > > > Hi, > > > > I've packaged the new version of this library, the upstream author has > > > > changed the SONAME, and so I've changed the name of the lib and -data > > > > package, not changed the name of the -dev file because the old > > > > maintainer has chosen to not version the package. > > > > > > > > This is my first library package, and I've some doubts, is for this that > > > > I'm asking for RFC... > > > > > > > > Is it correct to replace the old library? This can cause some breakage > > > > with old linked binaries (if any, I've seen that no package depends on > > > > this library)... > > > > > > audacious-plugins > > > libvisual-projectm > > > > > > You will have to at least update audacious-plugins to work before doing > > > this. > > > > ok, > > but about the name of the binary library package, is much correct to add > > the SONAME in the name of the package libprojectm2_1.2.0-1_i386.deb that > > replaces libprojectm1_1.01.0-1_i386.deb for example? or, considering > > that it is a small library a generic libprojectm_1.2.0-1_i386.deb? > > Debian policy requires that it be named libprojectm2. Please be sure to > read the policy manual before continuing. Yes, I've read it and I've read "Debian Library Packaging guide" too, I've asked here in mentors-list to have a confirm of my understanding of the documentation. Unfortunately this clarification is arrived too late and I've send to ftp-master a very bad package. My mistake, I've hurried without any reason... > > and to avoid breakage with audacious-plugins without updating > > audacious-plugins itself, can I, hypothetically, make libprojectm2 to be > > installable with libprojectm1? > > Audacious-Plugins actual code will have to be ported to the new API. The > new API has incompatible changes. > > See the lines in my previous mail with ^'s below them, for a more > detailed explanation about the breakage trend in projectM. please, this is not necessary, I've understood your previous email without any need of highlights, IMHO the point of my previous question was another... > > > > about the change of SONAME by the upstream author, is it correct to > > > > change the SONAME if the library is compatible with the old one? > > > > > > The library isn't compatible. Upstream breaks the API with every > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > release, so I gave up on them. > ^^^^^^^ > > API breakage results in ABI breakage, which means the SONAME must be > changed, and *applications ported to the new API*. again I've understood; you are speaking about this project in particular, my question has been (in my intention) more general... > At any rate, is there really any *point* in upgrading the library > anyway? The new versions do not introduce any new features that make the > effort worthwhile. I'm thinking about this. > If you can't handle this, then please do not take the package, or at > least wait until after lenny is released to do so. I can handle this, maybe I need to ask for some help, but I can handle this. Otherwise I would not have taken this package. Best Regards, francesco
Attachment:
signature.asc
Description: Questa =?ISO-8859-1?Q?=E8?= una parte del messaggio firmata digitalmente