Hi, i wrote: > > So if the Debian packaging software decides on its own that > > libisofs-1.5.2 is enough at package build time, then compilation > > [of libisoburn] will fail.
Alexandre Ghiti wrote: > In an ideal world, the symbols should be backward compatible and then the > 'symbols' mechanism should be enough: I'm curious, why would it be different > here? The ABI's of libburn and libisofs are indeed backwards compatible. I.e. it should be no problem to link an old libisoburn, Xfburn or Brasero with new versions of libisofs. What i prevent as upstream is that new libisoburn links with old versions of libisofs. Normally there is the hard reason that new symbols of libisofs being used. But there is also the reason to keep old bugs from infesting newer versions of xorriso. > > Is that file format specific to Debian and its derivatives or > > does it play a role in more generic build facilities ? > I can't really say, let's wait for the package maintainer on this. Well, half of this maintainer role is fulfilled by me. I care for upstream related aspects and try to keep some of the Debian tools happy with the package parameters on salsa. Dominique Dumont coaches me in respect to Debian packaging skills. He also has the last say about what i do on salsa and eventually risks his reputation by uploading our combined work. We have the lintian warning no-symbols-control-file since a while. If it is desirable to silence it by a more or less dummy symbol file, then i would develop a script which generates it from the existing .ver file. Dominque would then hopefully tell me how to integrate that script into debian/rules (or wherever it belongs). As stated above, there would be the risk of compilation failure with libisoburn, if we would give dpkg the opportunity to decide against the inner version demands of libisoburn. So i see only the option to have that dummy .symbols file which just says what is available now in the current version, but gives no version history. If .symbols were a general concept outside of Debian's packaging world, then i would consider to maintain it upstream and to keep libisoburn's inner expectations in sync with the .symbols file. (Normally it would still want the newest libisofs because normally new symbols there are introduced to fulfill needs of libisoburn and xorriso.) As it appears now from googling, i think Dominique can decide either that we leave out .symbols, or that we create the dummy symbols file. In the latter case i'd need coaching about generating the dummy under control of debian/rules. Have a nice day :) Thomas
