On 6.9.2017 05:28, Troy Curtis Jr wrote:
>
> >> > On 09/04/2017 06:21 AM, Troy Curtis Jr wrote:
> >> > > I have a version of the gpsd package which I
> believe
> >> addresses this
> >> > > ticket
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1390812.
> ...
>
>
> The gpsd upstream just announced the imminent release of 3.17
> (http://lists.nongnu.org/archive/html/gpsd-dev/2017-09/msg00003.html ).
> Some of the changes involve direct support of python3 and the ability to
> specify the target python build. So perfect for the Fedora python
> efforts! I've already checked the build with python2 and python3 with
> the tests on my F26 box locally, and have begun prepping the spec file
> for the 3.17 drop, complete with python2 and python3 subpackages.
Great news!
>
> So with that I have a couple of questions:
> 1. Since the PR for the python2 subpackage split just happened
> (https://src.fedoraproject.org/rpms/gpsd/pull-request/1 ), does it make
> sense to just delete that one and await the 3.17 version bump as well as
> the better versioned python support? And if so, would you prefer a
> squashed commit with all changes? Or is there no preference?
I don't think it is important. Either squashed or new commits, whatever
works for you. I would mention the 3.17 release in the PR and inform the
maintainers that you are going to update the change.
Done.
> 2. One change I noticed with 3.17 is renaming libgpsd.pc -> libgps.pc.
> This is a very sensible change, since the pkgconfig is for the library
> (libgps) and not the executable (gpsd). If the depending packages are
> looking for the old pkgconfig name, what is the best way to go about
> having the coordinated packages for them? Just mention in other PR for
> the downstream packages that the name change is dependent on this
> particular gpsd version?
Would symblinking the file back for backwards compatibility work? (I
haven't tried that with pkgconfig).
Yes it would but I was mistaken. libgpsd.pc was removed by the original spec file, and it was this removal line that was failing since upstream realized there was no point installing the file and stopped installing it. So never mind on that, I spoke up to soon.
But related, when there is a library version bump, does that cause a rev of the release version of all down stream packages to prompt a rebuild?