https://bugzilla.redhat.com/show_bug.cgi?id=1507103 --- Comment #74 from Fabio Massimo Di Nitto <fdinitto@xxxxxxxxxx> --- (In reply to Jan Pokorný from comment #73) > Ok, if the expectations are set like this, meaning that the future > obstacles I was worried about -- mostly related to parallel pkgconfig > files as their names form de facto inter-dependencies parallel of > API in RPM world (hence something that should be established wisely > since the beginning because once the client packages will start to > pick this "pkgconfig(libknet)", Pandora's box is open and maintenance > burden cannot be taken back) -- won't occur (all libknet clients will > need to be rebuilt for/ported to libknet2 at once on the single system, > and all the systems they want to communicate with unless compatibility > is preserved), I will conclude this extension of point G. with a simple > task to have in-spec comment above "%files -n libknet1-devel" to > express this explicitly, e.g.: > > > # libknet.pc leading to pkgconfig(libknet) automatic virtual provides, > > # like other files, is not explicitly versioned in the name like the > > # subpackages are -- intention of doing so for subpackage names is > > # to ease the cross-checking the compatibility of the remote clients > > # interchanging data using this network communication library, as > > # the number denotes the protocol version (providing multiple > > # protocol versions in parallel is not planned). > > %files -n libknet1-devel Good enough explanation. > > [I hope I picked the gist of the reasoning right, but really can't see > any other justification, to version packaged libraries like this all > the time may be common for Debian, but this is not Debian, hopefully > this is clear.] Let´s not mix up things please. Debian uses the soname there. > > This is in addition to summary tags per [comment 61]. > > * * * > > Regarding A., I can tolerate the situation as is provided there's: > > - clear promise to do something about that in the future > (I will follow-up on that github question to see if the original > use case cannot be handled by other means, which would be the > simplest solution, otherwise there are these casing options etc. > to be implemented if upstream-downstream sync is required) > > - comment above "%debug_package" that it is not relevant for > Fedora and its removal is pending ack. > > * * * > > Please, present the fixed spec file so I can recheck and approve > the review. -- 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
