On Tue, Oct 16, 2018 at 12:01:35AM +0100, Ian Jackson wrote:
> Josh Triplett writes ("Bug#904248: Beginnings of a patch to add netbase to
> build-essential"):
> > On Mon, 15 Oct 2018 13:39:32 +0100 Ian Jackson
> > <ijack...@chiark.greenend.org.uk> wrote:
> > > My proposed wording about "longstanding and conventionally available
> > > service and protocol names and numbers" says that if the admin has
> > > modified the file they need to make sure their modified version isn't
> > > toally borked.
> >
> > Which effectively means the admin should never delete any existing entry
> > in the file, only add their own.
>
> It's a config file. If you make semantically unwise changes to a
> config file you get to keep all the remaining pieces. I'm not sure
> why that is controversial ?
The baseline information is fundamentally not configurable. It's not a
config file, it's a data file. (I think one of the only arguments for
having it in /etc at all is needing to have it on / rather than /usr,
and that no longer applies.)
> > It doesn't seem reasonable for a package to require a particular entry
> > in a conffile in order to build. Packages should contain that
> > information themselves.
>
> Looking up protocols and services entries at build time was once
> regarded as good practice.
Yes. Once.
> And there is nothing particularly wrong
> with it.
It makes your package build depend on an external, *configurable* file,
rather than having a service responsible for foo know that foo typically
lives on port 1234. Why is that a feature rather than a bug?
> > Much like /usr/share/misc/pci.ids and other such databases that record
> > the state of the real world and standards committees, editing these
> > files at all seems questionable. Suppose, hypothetically, that these
> > files all moved to /usr/share/misc/ , and then libnss_files.so learned
> > to read both /etc/$file and /usr/share/misc/$file , with the former not
> > existing by default? (We could also switch to a faster lookup mechanism,
> > but let's not change too many things simultaneously.)
>
> This is all a lovely hypothetical world.
This is not hard to patch, if there's an inclination to do so. I'd be
happy to write such patches myself.
> > (This is separate from the problem that netbase should *still* not be
> > build-essential, as several have said on this thread. Personally, I'm
> > leaning increasingly in the direction of "even an explicit build-depends
> > on netbase should be treated as a sign of a bug in the package".)
>
> You don't seem to be addressing the same situation as I am at all.
Quite possibly. The situation I'm trying to address is "let's make
packages more robust, and have less essential/build-essential packages".
At the very *least* I don't think it's unreasonable to ask packages that
need netbase to build-depend on it.
> And you don't have any answer to gregor herrmann's point that these
> failures are not uncommon.
Many types of bugs are not uncommon.
> I don't understand what the huge objection
> is to this pretty harmless package.
A pretty harmless package here, a pretty harmless package there...
