ports/67970: ports textproc/libxml, textproc/libxslt: bogus
dependencies on devel/pkgconfig
Oliver Eikemeier
eikemeier at fillmore-labs.com
Wed Jun 16 03:20:36 PDT 2004
The following reply was made to PR ports/67970; it has been noted by GNATS.
From: Oliver Eikemeier <eikemeier at fillmore-labs.com>
To: Alexander Nedotsukov <bland at FreeBSD.org>
Cc: freebsd-gnats-submit at FreeBSD.org
Subject: Re: ports/67970: ports textproc/libxml, textproc/libxslt: bogus dependencies on devel/pkgconfig
Date: Wed, 16 Jun 2004 12:19:29 +0200
Alexander Nedotsukov wrote:
> Oliver, ports which installs *.la files installs them under existing
> hierarchy (and btw they better not to install them at all).
I agree, it was just an example.
> Let's try on clean machine pkg_add some; pkg_delete pkgconfig;
> pkg_delete some; Why empty libdata/pkgconfig leftover? Because we don't
> have something like installation reference counting in Solaris and
> run-time dependency fixes the situation here. This actually answer for
> your point two from original posting also.
Which leftovers? I can do pkg_add libxml; pkg_delete libxml (assuming
the dependency on pkgconfig is dropped),
and have no additional files left besides an empty libdata/pkgconfig,
which could be either added to the
plist or the mtree file (probably the latter is preferrable). Have you
any files on your machine where
pkg_which -v /usr/local/libdata/pkgconfig/*
can't determine the originating package?
> Now argument three from the same place. I beleive in most of the cases
> users do not requeired to rebuild ports which depend on pkgconfig
> because of version bump in last one. Why do you think they have to?
Ok, perhaps my argument is a little weak here. I could construct
scenarios, but whatever,
lets just drop this point. You are right here.
> Add here my feeling that argument one is pretty much artificial. Users
> will fetch, build and install pkgconfig anyway.
No. I wouldn't.
> Well not at the libxml build time (with your proposed solution) but I
> bet just after it. The reason is simple. For the user (not developer)
> libxml itself have zero value. And when s/he start to build port which
> depends on libxml pkgconfig requirement will be unavoidable.
Nope. xmllint and xsltproc are pretty valuable. When you set up a small
server generating portaudit database
files from the XML sources, you end up depending on pkgconfig. No big
deal, but pretty useless. I might
want to remove it from my server.
> For my understanding the right way how situation may be fixed is to
> patch bsd.gnome.mk and add fake-package which un/install
> libdata/pkgconfig. This will complicate things a bit but do not lower
> dependency lists though. We only get small advantage in size <40K
> overall.
As far as I understand, pkgconfig is only used when *building* gnome
applications, so application should
inherit a build dependency from bsd.gnome.mk. This should completely
eliminate the run dependency, and
conform with FreeBSD standards.
> Btw libxml just one case of many we already have. Do you realize this?
I assumed this, but wanted to use a real-world example that actually
makes sense. I end up with pkgconfig
on all my servers (including jails), none of them having any X clients
installed. Ok, I can spare the 40k,
but it violates FreeBSD standards (build vs. run-time dependency) and is
pretty useless in my case. There
may be other libraries with the same problem.
Also note that I do not oppose to install the .pc files. Although I
don't need them, I understand that they
belong to the libraries and are useful. It's just the dependency of a
library on a build tool that should
be eliminated.
-Oliver
More information about the freebsd-gnome
mailing list