[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ✘contrib/gpssubframe
From: |
Greg Troxel |
Subject: |
Re: ✘contrib/gpssubframe |
Date: |
Fri, 18 Sep 2020 19:49:49 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.3 (berkeley-unix) |
"Gary E. Miller" <gem@rellim.com> writes:
>> Do you intend to move it out of contrib when you are happy with it?
>
> Yes. And after it has a man page, examples, and more validation.
> I expect before next release.
>
>> My take as a packager is that things in contrib don't really belong
>> in a package but this seems like it should be installed.
>
> NTPsec going through similar discussions. They have contrib, attic,
> and more.
>
> Only a subset of gpsd users use ubxtool, and only a small subset of
> those can use gpssubframe. Plus some a few others that have receivers
> with subframe output.
>
> I don't like packages that remove gpsd clients, like cgps, to separate
> packages. For gpssubframe it may make sense, but not my call.
I don't think it makes sense, but pkgsrc has a different set of notions.
Basically:
We don't have a notion of building a giant package with the union of
needed dependencies and then partition the files into N packages.
options in packages are awkward, because binary packages are built
the standard way
it makes sense to split/option to avoid painful dependencies (like
QT), but omitting a script or C program that can just sit there if you
don't want it doesn't help much
So a program the can be built using the things that are already required
for the rest of gpsd has basically zero cost to be in a package.
For gpsd, the only big deal is gtk, and these days that's ok for normal
computers and part of what you omit for embedded.
So I'd say leave it in, and don't worry.
If someobody is actually troubled by the presence of ubxtool and
gpssubframe, I'd like to understand that. But ubxtool is ~350KB of
python.
signature.asc
Description: PGP signature