Re: [gpsd-users] GPSD on Debian 10 (buster): allowing other hosts to access gpsd

[Bernd Zeimetz]

On 9/29/19 11:25 PM, Gary E. Miller wrote:
>> Which makes life for (almost) all distributions really hard.
> 
> I fail to see how the numbering system affects anything.  Linus uses
> the number of his toes (20).  If you prefer from now on 3.19.1, then
> 3.19.2, then that is possible.

I'm not asking for a different way how releases are being named. I'm
asking for stable point-releases which do not change the abi/api, but
only fix bugs.


>> A distribution can't just upload a new packages, neither to the
>> current testing/development branch, nor to stable releases.
> 
> And yet, many manage to do that just fine.

There are some differences:
- some distributions just don't care if something breaks for some time
- some have paid developers...
- some are much bigger than others and do not have paid developers.


> Also, a lot depends on your definition of "new".
> 
>> The thing that needs to happen first is that all reverse dependencies
>> need to build fine against it.
> 
> AFAIK, there are no reverse dependencies to gpsd.  If you know of
> some, please contribute that information.

Reverse Build-depends in main:
------------------------------

alfred
collectd
direwolf
foxtrotgps
marble
navit
osmo-bts
plasma-workspace
s3d
uhd
viking

Found a total of 11 reverse build-depend(s) for libgps-dev.

(Two more were removed recently, aweather and obdgpslogger



>> Which usually just does not happen. If you break the API in a way that
>> reverse dependencies don't build anymore, it takes several weeks to
>> months to fix those. For example - you can't just upload a new KDE
>> without coordination.
> 
> Agreed, but sometimes unavoidable when nthe API is fatally broken.
> 
>> To put it into hours, if this happens, its a 20-40h maintainer work
>> just to get everything in a shape to accept the new gpsd release.
>> Then the upload needs to be coordinated.
> 
> We are here to help.

Nothing you can help with, except you want to provide patches for ~half
of the projects mentioned above.


>> Uploading gpsd requires several big and deeply integrated packages to
>> be rebuilt.
> 
> Um?  Care to specify?  The only thing I can think of is the doc stuff.
> The doc stuff has been stable for a while.
> 
>> That alone is not the problem, it happens automatically.
> 
> Oh, well then, why bring it up?

We can't rebuild the everything every other day, transitions need to be
coordinated.

>> But we also have other transitions that trigger a lot of rebuilds, so
>> things need to be coordinated. Which takes some more time and
>> ressources. Then gpsd is in a development release.
> 
> Every distro handles that transitions differently.  Is there something
> gpsd should do differently in there?

If you change things that need code changes in the projects which are
using libgps, warn early. As soon as they land in git would be the best
time...
Avoiding soname bumps if possible would be nice, also (I know its not
always possible, but often it is.

>> For stable releases, this is impossible.
> 
> Fair enough, but shipping 5 year old gpsd in a new "stable" release
> is unfair to the gpsd users.

5 years old? Please don't talk bullshit.
3.17: 2017-09-07. That is two years ago.
3.18: 2018-10-02 - we had a transition freeze on 2019-01-12 - two months
are just not enough time to fix all packages which failed to build with
the new release.


>> We can't rebuild the whole archive. All we can do is to fix bugs
>> without breaking other things. So..
> 
> Yeah, boxed yourself in there, didn't you?

What do you mean? We've fixed the CVEs and at least those bugs in json.c
in buster, and the CVE in oldstable... I had a look through the commit
logs and actually asked on irc and by mail to esr if there is something
else to fix, I did not get a reply - and I was not able to find another
pickable commit. Don't blame me..


>>> Oh, wow, did you really just say that?  I happen to beleive all
>>> bugs, of all severity, are important.  
>> ... yes, all bugs are important, but we can only port fixes easily,
>> that don't break the ABI/API. There is no way to backport every single
>> bugfix, so we have to stick with the really important ones. And we
>> basically do this based on CVEs. Or if upstreams tell us, that
>> something should be fixed. We can fix all issues in point-releases,
>> if we know about them and if the fix in backportable.
> 
> Looks like we agree, neither of us has time to to the others work
> for them.
> 
> And I'm with Linus on this one, flagging changes as CVEs, or critical,
> just helps the black hats.  The kernel does not do it.

Should I get you the list of CVEs in the kernel?
But the kernel people also tell distributions if there is something
broken, so thats not an issue at all.


>> So basically *you* need to tell the maintainers which issues need to
>> be backported, and which ones are bad enough that they need a CVE or
>> at least a security upload.
> 
> I'm 100% against backports.  I am 100% with Linus that they are a sore
> upon humanity.  If you feel the need to do that, then check the gpsd git
> logs, issues and MR's.

Even the Linux kernel has LTS releases which are maintained for years...


>> Also: if a patch can't be backported due to abi/api breakage, a new
>> one needs to be developed.
> 
> Feel free.
> 
>> This is something that is done by all sane upstreams, and actually I'd
>> expect that from gpsd, too, as it is a rather important piece of
>> software.
> 
> If that were true, then gpsd would not be constantly having to patch
> for upstream changes.
> 
>> So basically we have three options:
>>
>> - maintainers do the point release - without deep code knowledge and
>> knowledge about which bug will fix what, this won't be perfect. We
>> like to stick to CVEs and to everything UPSTREAM tells us to fix.
>>
>> - you do proper point releases. Bug fixes only, no abi/api breakage.
>> We take them, ship them, easy to do.
>>
>> - we remove gpsd from distributions...
> 
> I guess I'll take #3.  Not enough man power for the first two.  #3 will
> save us a lot of time helping people with broken packages.

Oh and it will save me a lot of time I seem to be wasting to package gpsd...

Those packages are not broken. What you see are those who don't know how
to use Linux. Do you really want to help them to compile gpsd and have a
ton of old, never updated installations out there?



-- 
 Bernd Zeimetz                            Debian GNU/Linux Developer
 http://bzed.de                                http://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F