On Tue, Aug 07, 2018 at 04:35:14PM +0200, Julien Cristau wrote:
> On 08/04/2018 07:14 AM, Ian Jackson wrote:
> > Sean Whitton writes ("Beginnings of a patch to add netbase to
> > build-essential"):
> >> Ian also thinks that package builds should be able to access the
> >> information normally contained in /etc/protocols and /etc/services by
> >> means of the C standard library.
> >
> > Yes.
> >
> >> Could you say more about why this is needed, and provide wording for a
> >> third bullet point in the list in my patch, which describes the
> >> functionality of /etc/protocols and /etc/services, please?
> >
> > Sorry for the delay replying to this.
> >
> > I think this is needed because some build systems look at
> > /etc/{services,protocols} at build-time to (for example) bake into the
> > program the default port number, or, in some cases, protocol numbers.
> > The values in these files are largely fixed or conventional, so this
> > is quite appropriate. Expecting programs to add explicit dependencies
> > on netbase for this seems silly - there is little benefit, since the
> > files are small and the implementation of the lookup where done via
> > the libc) is part of the libc. And of course any notionally-missing
> > dependencies on netbase would not be discovered.
> >
> > I suggest this text:
> >
> > - for the package build to look up longstanding and conventionally
> > available service and protocol names and numbers, either by
> > directly reading /etc/services and /etc/protocols or by using the
> > corresponding functions from the C standard library. (If the
> > package needs to look up a more recent service or protocol, and
> > certainly if the service or protocol was not listed in these files
> > in the package's targeted Debian releases, an appropriate
> > versioned build-dependency is needed.)
> >
> FWIW I disagree, I expect this is rather nice usage and so requiring a
I assume you mean niche usage.
> build-dep on netbase for the few packages that need this isn't a
> problem. Plus, these files being conffiles means you can't actually
> rely on finding anything specific in there anyway.
Yes this is something I am concerned too.
Cheers,
--
Bill. <ballo...@debian.org>
Imagine a large red swirl here.
