On Wed, 2022-06-08 at 14:03:06 +0000, Lance Lin wrote: > > Ideally the .a archive and the .so linked script (which just redirects > > the linker to always use the .a archive, so there's no actual shared > > library), should be moved into the libsrpc-dev package as the usual > > convention. The versioned .so symlink (libsrpc.so.0.9.5) should be > > removed, as there should be no object dynamically linked against that > > (given that it points back to the .so linker script which does not > > resolve at run-time) to avoid confusion. > > Please help me understand. When I packaged 'workflow' for the upstream > authors, I created libworkflow1 and libworkflow-dev. libworkflow1 provides > the libraries/objects while the -dev package depends on libworkflow1 and > includes the header files. I thought this was the convention?
Not really no. The workflow packages look like needing further fixing too, I'll file a report for that one separately. :) The .a and .so pathnames are shipped in the -dev package because they are only useful during development, and because they contain unversioned pathnames that would otherwise conflict with their counterparts from other supposedly co-installable shared library packages. The point of versioning the shared library packages is precisely so that they can be co-installed, which makes (distro) transitions and system upgrades way smoother. Say bin-pkg-a links against libsome1 from the libsome source package, then libsome gets updated and bumps its shared library package to libsome2 which bin-pkg-b links against. This means a user can happily have bin-pkg-a โ libsome1 and bin-pkg-b โ libsome2 installed at the same time while the others get rebuilt, this also means packages can be rebuilt against a later version libsome-dev โ libsome2 even if they transitively Build-Depends on something that depends on libsome1, otherwise that build-dependency chain could not be installed. This is covered in debian-policy ยง8. > > Then the srpc_generator program would be moved into a new libsrcp-bin > > binary package to make this separation more clear. And the libsrpc > > binary package can then be dropped. (All with the required > > Replaces/Breaks relationships.) > > > > > At that point the libsrpc-dev can be marked as Multi-Arch: same, and > > the libsrpc-bin (assuming the generated contents are arch-independent) > > can be marked Multi-Arch: foreign. > > OK. This is doable. I was unsure how to structure the package to include > this binary. > > I based my packaging of SPRC based on workflow and both passed the mentors > list. If there is a better or more standard away of doing things, I am > happy to adjust. See above. > Is there a system in Debian that flags this "unorthodox" organization for > review? It seems lintian does not have any check for something like this, it does notice other things, such as the Section for libsrpc-dev being wrong and the Architecture, but nothing more. I guess the problem is the combination of unversioned shared library package, with no actual shared library and instead a linker script, which all are rather unusual. > I'm curious how you came across this since workflow was done in a > very similar fashion but no one commented. I am always learning and want > to make sure I fix errors made in the past and avoid them in the future. This specific case I noticed as I tend to check any unversioned shared library package that appears as a new package on aptitude. Otherwise I'd probably have not noticed, like the workflow one. Also I guess not all reviews are made equal. :) > Do you have a reference package I could look at? It would be helpful > to base my work off of something that meets the standard. The libbsd source package also ships a linker script as its .so pathname, even though that one contains an actual shared library with a versioned SONAME. For a more usual package, perhaps libmd would do. Thanks, Guillem
