https://bugzilla.redhat.com/show_bug.cgi?id=1507103



--- Comment #73 from Jan Pokorný <jpoko...@redhat.com> ---
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

[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.]

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

* * *

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@lists.fedoraproject.org
To unsubscribe send an email to package-review-le...@lists.fedoraproject.org

Reply via email to