Hi, On 31/07/17 14:50, Marcelo Roberto Jimenez wrote: > I personally don't like that change of names. I agree that it is not the > proper way to do it. It was done as a temporary hack to allow both libs > to be installed. Since libupnp 1.8 is finally advancing, this should no > longer be the case. > > So, I think libupnp should come back to the proper naming scheeme, but > IIRC, some Debian apps will be affected, since installing both libs has > been a Debian request.
This appears to where it was decided? I'm not sure I can remember asking you to change the package names. https://github.com/mrjimenez/pupnp/issues/15 The argument in that thread is about co-installing libraries. This isn't a problem for Debian (at runtime at least) because the libraries and headers are in separate packages. It may be an issue for other distributions though. There is currently nothing in Debian depending on libupnp 1.8 so large changes such as this are not a problem at the moment. Thanks, James > On Fri, Jul 28, 2017 at 12:05 PM, Jean-Baptiste Kempf <j...@videolan.org > <mailto:j...@videolan.org>> wrote: > > Hello Sebastian, Bugreporters, > > On Fri, 21 Jul 2017, at 14:58, Sebastian Ramacher wrote: > > > On Thu, Jul 20, 2017 at 02:34:42PM +0200, Sebastian Ramacher wrote: > > > > > currently there are two versions of libupnp in the archive > (libupnp6 and > > > > > libupnp-1.8-10). To be able to remove libupnp6 (i.e. the older of > the > > > > > two) it is necessary to port vlc (and all other rdepends) to > > > > > libupnp-1.8. > > > > > > > > > > The patch below implements this for vlc. With this applied I can > still > > > > > playback videos with vlc. > > > > > > > > As long as the adoption to upnp 1.8 requires to add -1.8 everywhere > (are we > > > > supposed to change it to -1.9 next month with the next upstream > release?), this > > > > was explicitly NAKed upstream. > > > > > > Which upstream? vlc I suppose? Do you have a link to the discussion > > > handy? > > > > Yes, vlc upstream. This was over IRC and I don't have logs. But I'm sure > > J-B > > will repeat it if necessary (CCed) > > Sure. > > Since when releasing a new version of a library requires changing all > the includes and all the pkg-config detection? > > SO names are done to notate API/ABI changes within a library and > PKG-CONFIG files are done to show where to find the includes folder and > how to link. > > If you do a moderate breaking change, you change the API, the ABI, and > bump the library version name majorly. And people linking against you > will need to adapt, when they bump the requirements. This was done for > almost every minor C/C++ library, since forever. > > So, sorry, but this way of renaming the headers folder name and changing > the .pc files is completely backward; and sorry, totally not justified, > because it's justified for complete rewrites, not for a moderate change. > > If you want to do that anyway, at least provide the same .pc file name > which gives the new includes. > > Best, > > > -- > Jean-Baptiste Kempf - President > +33 672 704 734 <tel:%2B33%20672%20704%20734> > >
signature.asc
Description: OpenPGP digital signature
