On Thu, 2023-05-04 at 09:21 -0700, Russ Allbery wrote:
> Sam Hartman <hartm...@debian.org> writes:
> 
> > We could represent this as a dependency or a recommends if there is
> > some
> > special reason that libkrb5-dev needs the dependency.  krb5-config
> > not
> > working alone is not enough to justify a depends relationship: as I
> > understand it (Russ please correct me if I'm getting this wrong
> > from
> > memory), the policy requirement is not that every program in a
> > package
> > work with the installed dependencies, but that the package as a
> > whole
> > work.
> 
> Right, the requirement is that the core functionality work, but some
> things may not unless Recommends and Suggests are met.  But we don't
> put
> Recommends and Suggests of compilers on every *-dev package either,
> so I
> think *-dev packages are a bit of an unenumerated special case.

Agree. I found this issue in a more complex dependency chain of python
packages, where one package called this tool during during the build of
the wheel (pip of course...). In the end, `krb5-config --cflags krb5`
was called, which will definitely be consumed by a c compiler (and by
that build-essential should be installed anyways).

However, when looking at the manpage of krb5-config, not all options
are actually related to the build environment. That's why I opened this
issue, as the tool cannot be used at all in case no compiler is
installed. If this is acceptable according to the debian policies, we
can also close this bug.

> 
> > I.E.  I could say that we care far more about the pkgconfig .pc
> > files,
> > krb5-config is legacy, and so policy does not force us to depend on
> > a
> > compiler even though krb5-config is kind of useless without it.
> 
> I would argue that the pkgconfig .pc files are also fairly useless
> without
> a compiler, just with one more step of separation.  :)  I could

IMHO this is somehow different, as .pc files are basically just
configuration and the pkg-config tool also works without having a build
environment.

> imagine
> theoretical use cases where one wanted to inspect what flags would be
> recommended without using them on that system, but I would want to
> know
> that someone encountered that situation in the real world before
> worrying
> too much about it.
> 
> My personal experience watching folks who are new to Debian who want
> to
> compile something is that they encounter the missing toolchain
> somewhat
> randomly and attribute that to somewhat random missing dependencies
> until
> someone points out they should just install build-essential if
> they're
> going to be compiling software, and then they encode that in their
> normal
> practices and resolve the problem that way.  This isn't the most
> user-friendly setup, to be sure, but I wonder if the path is to more
> prominently document that people should install build-essential or
> the
> equivalent if they're going to be building software, rather than
> adding
> individual dependencies.

Agree.

Felix

> 
> If we go down the dependency route, IMO it should be handled by
> debhelper
> or similar machinery; I don't think libkrb5-dev is particularly
> special in
> this regard, so fixing this in the krb5 package feels wrong to me.
> 
> > There does appear to be a c-compiler virtual package.
> > We could depend on gcc|c-compiler.
> 
> Oh, there is indeed, sorry.  I missed that because I was looking at
> the
> clang package instead of the clang-16 package.
> 

Reply via email to