Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 16 Jun 2004 10:20:25 GMT
From:      Oliver Eikemeier <eikemeier@fillmore-labs.com>
To:        gnome@FreeBSD.org
Subject:   Re: ports/67970: ports textproc/libxml, textproc/libxslt: bogus dependencies on devel/pkgconfig
Message-ID:  <200406161020.i5GAKPVk017868@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help
The following reply was made to PR ports/67970; it has been noted by GNATS.

From: Oliver Eikemeier <eikemeier@fillmore-labs.com>
To: Alexander Nedotsukov <bland@FreeBSD.org>
Cc: freebsd-gnats-submit@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
 



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200406161020.i5GAKPVk017868>