Re: [gpsd-dev] Planning a 3.11 snap release

[Greg Troxel]

"Gary E. Miller" <address@hidden> writes:

> Greg Troxel <address@hidden> wrote:
>
>> I think fetching things at build time is basically broken. 
>
> A lot of packages fetch at build time.

I don't think that's true.  I've packaged quite a few things and
maintained many more (within pkgsrc), and I can't name another one.  I'm
sure they exist, but it's an edge case, not within normal, in my experience.

> We certainly want to stay
> compatible with the standard and simple build procedure:
>       tar -x gpsd.tar.gz
>         cd gpsd-XX
>         scons install

That's being selective about defining standard, and a circular argument.
Part of the normal definition includes not trying to use the net, and
just invoking "./configure && make && make install" (with accomodations
for other build systems).


gpsd here seems to have a typical problem of many projects, where it
views itself as very special, and worthy of deviating from norms.  Those
arguments sort of make sense when you view only one project.  But when
you view 10000 projects, 1000 of which want to be special, things get
out of hand.   It's in that context that I look at cost/benefit.

I suggested having a build step to freshen the leapseconds data.  It can
be "scons fetch", and packaging systems that want to do that can do it,
while "scons" (build) can act within the norms.  I bet most packaging
systems will not want to run the fetch, but we can see.

As for fetching being normal for licensing, I don't think that's true
either.  Packages with non-free licenses often have fetching issues, but
the typical solution is to make the difficult part a dependency.  At
least in pkgsrc, automatically fetching non-Free code would not be
allowed in a package marked as Free, and I bet Debian is at least as
hard-core about that if not more so.

pgp9aqVkCUY0t.pgp
Description: PGP signature