https://bugzilla.redhat.com/show_bug.cgi?id=1764813 --- Comment #11 from Neal Gompa <ngompa13@xxxxxxxxx> --- (In reply to Dridi Boukelmoune from comment #10) > Apologies for being late to the game but I have some remarks. > > We should avoid listing %{_libdir}/*.so.* as this might lead to unattended > sonames bumps. > The library interface isn't stable, but sure, I can change this to track the soversion... > Also as per the guidelines I think we should follow upstream (sub)packaging > as prior art: > > - apt-libs: split into libapt-pkg and libapt-inst The splitting is unnecessary. Moreover, libapt-inst is gone now. > - libapt-pkg: make it provide libapt-pkg%{soname} What would be the point? I can do it, but the generated library Provides are what we usually rely on for this... > - libapt-inst: make it provide libapt-inst%{soname} This library is gone. > - apt-devel: rename to libapt-pkg-devel > - apt-devel-doc: rename to libapt-pkg-doc > I'm not going to do this. People should not rely on package names like this when building against it. Instead, they should rely on pkgconfig() / cmake() Provides that RPM generates. That said, I already include those names as Provides for the subpackages in question. > I'm very much in favor of not having the dummy apt-transport-https package > at all, and only provide it in the main apt package. > I'm currently adding the virtual Provides for it in the main package. Keep in mind I've been tracking changes in upstream for three years now. My spec file went through all the transitions related to that transport plugin. > See the upstream source package for reference: > https://packages.debian.org/source/buster/apt > I've been following what's been going on in salsa.d.o, so I'm aware of what has been changing there. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx
