Unexpected dependencies of graphics/libGL
freebsd at edvax.de
Thu Jan 21 03:11:15 UTC 2016
On Wed, 20 Jan 2016 14:44:57 -0500, Michael B. Eichorn wrote:
> On Wed, 2016-01-20 at 18:42 +0000, Luís Fernando Schultz Xavier da
> Silveira wrote:
> > Indeed. As I have said, it is the proper tool to build package
> > repositories.
> > Maybe I should have rephrased myself as in
> > "If the extra dependencies compromise the jail, the output packages
> > can be compromised and, when installed, compromise the host
> > system."
> > We can not live in a dreamland and expect that when a software
> > malfunctions, it will be kind enough to output an error message and
> > end with a non-zero exit code. It may also signal success but affect
> > the binaries and files contained in the resulting package. However,
> > as someone pointed out, I am repeating myself.
> Ok, I think I see what your concern is now. I accept that you are
> correct that building only what is necessary is safer.
If you review the thread from its beginning, you will find that
the initial discussion went something like this:
"I want to install libGL, and it installs Git and Bazaar which
I do not need and not want on my system."
"Those are probably B-Deps. How about installing via pkg?"
"No, I want to install from source. But there is no configuration
option for leaving out those dependencies. Should I notify the
The only thing I'd like to add is that it is possible that those
dependencies do not originate from the libGL port, but maybe from
one of its dependencies.
> I think the disconnect was that avoiding installing B-deps also
> improves security and using poudriere to do this is relatively easy.
Correct - the initial problem is just moved from the host system
into a jail. This helps dealing with the problem, but does not
remove it, together with the possible security and bloat considerations
involved when installing "layer cake" of dependencies.
> Building only what you need is hard. It does take time and effort to
> provide the configure options in the ports tree. As such it is
> reasonable that porters might not choose to include every possible
> case. However if you think an important one has been missed it is
> reasonable to get in touch with the port owner and see if they will add
> a configure option.
This has been my suggestion. If tools are really optional for building
a certain piece of software, they should have a configuration option
to turn them off. Does libGL _really_ need Git and/or Bazaar to be
built (or to run)? Then such an option would be futile because unchecking
it would prevent the port from building. This is a decision the port
maintainer has to make, and act accordingly when crafting the options
for the Makefile.
I know this is not trivial, but surely possible.
> I think the list assumed that if your concern was not addressed by a
> configure option it probably was either an oversight or not worth the
> effort to have the option. And that if it was an oversight the port
> owner would have fixed it on request. As such we incorrectly jumped to
> the next best solution, not installing the B-deps.
His considerations concerning security are fully valid, and in case
of common bloat "addiction", there is a certain risk that we, the
users, take it for granted to install tons of stuff on our host system
(or build jail), not noticing that we might introduce security problems
we are not fully aware about...
The words about trusting the port infrastructure apply. If you don't
trust the build facilities (official Poudriere, local build system or
jails), you should not trust packages either, and vice versa, because
all their results originate from the same source and procedures. Allowing
a port to compromize this essential structure (and even if it's just
someone's sloppyness deep inside the dependency "layer cake") is not
a good idea.
To resume: When the OP found out that libGL wants to install Git and
Bazaar when building from source, he discovered something strange that
is worth having a look at. I don't see any "trolling" in this action.
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
More information about the freebsd-questions