--- Comment #74 from Fabio Massimo Di Nitto <> ---
(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


> * * *
> 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 --
To unsubscribe send an email to

Reply via email to