Spec URL: http://declera.com/~yaneti/libhandy1/libhandy1.spec SRPM URL: http://declera.com/~yaneti/libhandy1/libhandy1-0.9.90-1.fc33.src.rpm Description: libhandy provides GTK+ widgets and GObjects to ease developing applications for mobile phones Fedora Account System Username: yaneti libhandy1 is packaging the first stable API of libhandy, currently in pre-release
This review request is mostly a proposal. Won't go in if the current libhandy package goes a different way
It probably makes sense to update libhandy to the v1 API version and then create a libhandy0 compat package for legacy usage (unless there's no legacy usage to speak of).
I'm fine either way and don't have a strong opinion if should be libhandy and libhandy1, or libhandy and libhandy0, or libhandy1 and libhandy0 :) Yanko, I think you get to decide how you want it since you're the one doing the work here. I see you've done explicit Conflicts with libhandy-devel, why is that so? Can we avoid that somehow? Is it gtk-doc files conflicting? Can you split them out to a subpackage in that case, or ask upstream to include the library version in the gtk-doc file paths or something?
(In reply to Kalev Lember from comment #3) > Yanko, I think you get to decide how you want it since you're the one doing > the work here. That's not really true. This is specified in the Packaging Guidelines: https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#multiple According to these rules, the package names should be libhandy and libhandy0.
- I feel the libhandy situation is more gtk,gstreamer like so the libhandyN name makes more sense to me - To kalev's question about the conflict. I think in 99% it makes zero sense supporting parallel installable _devel_ environments for the same library. just my 2c. To whomever cares enough, please do whatever you feel is right. Sorry for the noise.