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

[Gary E. Miller]

Yo Bernd!

On Sun, 29 Sep 2019 23:01:36 +0200
Bernd Zeimetz <address@hidden> wrote:

> to summarize everything in one answer:
> 
> I know that you are not doing point-releases.

Um.  What about 3.18.1?

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

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

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.

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

> 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?

> 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?

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

> 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?

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

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

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

Feel free to suggest some practical suggestions that may be possible.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        address@hidden  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin

pgpjvHQ_ZSJ1X.pgp
Description: OpenPGP digital signature