ports/115870: [DEPS] graphics/cairo reduce X dependencies

[Alexander Leidinger]

Quoting Pav Lucistnik <pav at FreeBSD.org> (Tue, 04 Sep 2007 15:47:59 +0200):

> Alexander Leidinger píše v út 04. 09. 2007 v 15:38 +0200:
> 
> > Increasing the number from e.g. 3 to e.g. 20 does not slow down that
> 
> No, only tenfold.

On paper, but what matters is if the the wall clock time changes
significantly or not. As said, without numbers there's no reason to
discuss this now.

> > > You are operating on false assumptions here. Let me explain how libtool
> > > on FreeBSD work. It explicitly passes all indirectly required libraries
> > > to the linker during build. So they all get recorded in the shared
> > 
> > AFAIK it operated like this in the past, but not now anymore (it was
> > one of the complains des(?) had with the autotools ports, it is not
> > present in the old libtool versions, but AFAIK it is present in a
> > recent libtool version). I will check this to make sure it works and
> > come back to you with the result.
> 
> Go check; I believe it still does this.
> 
> > BTW: I just checked for gtk20 after my last mail. They have .pc files
> > for the installed and uninstalled case. The uninstalled case lists
> > the .la file in the build directory together with all dependencies. The
> > installed case lists the compiler flags together with all dependencies.
> > I'm in the process of testing the removal of the dependencies from
> > the .pc file for the installed case.
> 
> I seriously doubt gtk20 port maintainers will accept FreeBSD specific
> hackery on installed .pc files.

You mean more hackery (one reinplace command) than already existing (I
don't count the reinplace things in USE_GNOME=gnomehack now)?

Apart from this, I'm looking for a more generic solution (which would
be beneficial to other OS which recursively resolve libs too).

> > And regarding the "better be safe than broken" part... we all know
> > about the mails after a KDE/GNOME/X11/... update. So far there where
> > bugreports all the time after a major upgrade. Some problems are
> > because of missing dependencies, some are because of missed
> > portrevision bumps. By listing the explicit depends you get rid of some
> > complains (no missed libs, ability to check for more affected ports
> > than now). And by adding a check-script to pointyhat runs, you can even
> > get the big picture and are not limited to your local testing.
> 
> I'd like to split the debate into two parts
> 
> 1) dependency validation script, a tool for maintainers, portlint style
> 
> A good thing, no question.
> 
> 2) recording all indirect dependencies explicitly in ports
> 
> A bad thing, a total no go.

There seems to be a misunderstanding on your side. Sorry if I failed to
tell you about my intentions in a clear way. I agree totally with you
here. I don't want to record implicit dependencies explicitly in ports.
Only those with direct symbol references in the binaries. If there's no
direct reference to symbols defined in libpng, there should be no
reference to libpng in the binary of a port. That's the reason why I
look into the .pc files now (removing superfluous dependencies in a
portable way so it can go into the official tarballs).

Don't be scared, this is nothing which will go into the tree "soon". I
expect that I have to fix several bugs before I can offer a patch with
the explicit dependencies for testing. And after the patch is
available, it will take some time until is in a state where we can have
a look at statistics and discussing it in detail. Please don't judge
before you've seen the complete implementation, I'm at the beginning of
the work and there will be several changes needed.

Bye,
Alexander.

-- 
By pressing "Scroll Lock" you can use the arrow keys to scroll backward
through the console output.  Press "Scroll Lock" again to turn it off.
http://www.Leidinger.net  Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org     netchild @ FreeBSD.org  : PGP ID = 72077137