From owner-freebsd-gnome@FreeBSD.ORG Wed Jun 16 14:43:39 2004 Return-Path: Delivered-To: freebsd-gnome@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C20516A4CE for ; Wed, 16 Jun 2004 14:43:39 +0000 (GMT) Received: from e0-a11.b1.lan.prg.vol.cz (e0-a11.b1.lan.prg.vol.cz [195.122.204.152]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA08D43D5D for ; Wed, 16 Jun 2004 14:43:38 +0000 (GMT) (envelope-from pav@oook.cz) Received: from pav.hide.vol.cz (localhost [127.0.0.1])i5GEg7bx053764; Wed, 16 Jun 2004 16:42:07 +0200 (CEST) (envelope-from pav@oook.cz) Received: (from pav@localhost) by pav.hide.vol.cz (8.12.11/8.12.11/Submit) id i5GEg6Ha053763; Wed, 16 Jun 2004 16:42:06 +0200 (CEST) (envelope-from pav@oook.cz) X-Authentication-Warning: pav.hide.vol.cz: pav set sender to pav@oook.cz using -f From: Pav Lucistnik To: Oliver Eikemeier In-Reply-To: References: Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable Message-Id: <1087396926.41656.34.camel@pav.hide.vol.cz> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 16 Jun 2004 16:42:06 +0200 cc: gnome@freebsd.org Subject: Re: ports/67970: ports textproc/libxml, textproc/libxslt: bogus dependencies on devel/pkgconfig X-BeenThere: freebsd-gnome@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GNOME for FreeBSD -- porting and maintaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2004 14:43:39 -0000 V st, 16. 06. 2004 v 16:24, Oliver Eikemeier p=ED=B9e: > >>>> the .pc file in the base and add libdata/pkgconfig to the mtree=20 > >>>> files, > >>>> especially since there are more ports that have problems with that. > >>> > >>> Adding libdata/pkgconfig to mtree sounds like a good idea. Depends ho= w > >>> broad mtree should be, that depends on portmgr's vision. > >> > >> Yep. otherwise a simple INSTALLS_PKGCONFIG=3Dyes would do the trick, > >> although it seems like we would only exchange a single line in > >> pkg-plist with one in the Makefile in this case. > > > > Note that this is not a solution to our debate, it merely masks the > > leftover empty directory if installing .pc file without pkgconfig > > dependency. >=20 > I'm not sure whether I understand this fully, especially `masking'=20 > leftover empty directories? This does not resolve dependency debate below, it merely takes care of libdata/pkgconfig directory in case we got for build_depends on consumer. > >>>> OTOH you seem to selectively ignore the other samples given, which=20 > >>>> does > >>>> not seem very wise to me either. I can not understand why you have=20 > >>>> such > >>>> an emotional relation to a plainly wrong dependency. > >>> > >>> I talked with you on the subject extensively on IRC yesterday, and > >>> you're firmly rooted in your believes and opinions. No reason to=20 > >>> repeat > >>> whole conversation over email again. > >> > >> True, and I aborted the discussion because it got emotionally heated. = I > >> submitted the PR in the hope of starting a more technically oriented > >> discussion, like getting some examples of breakage when this dependenc= y > >> would be removed. I'm a little disappointed of the lack of real=20 > >> arguments > >> in this thread. Most of my questions remain unanswered, like whether=20 > >> you > >> believe devel/valgrind, devel/pcsc-lite, print/freetype2, graphics/png= , > >> www/neon, www/openvrml, x11/XFree86-4-libraries and x11-toolkits/qt33 > >> should run-depend on pkgconfig too. > > > > Yes, I do. >=20 > I guess you will not get many people to agree to this. Besides, since > they currently don't (and there are more of them) you have to=20 > build-depend > applications linking with those on pkg-config anyway. Perhaps no one tried to link them using pkg-config yet. I've seen ports installing .pc files to lib/pkgconfig, which is plain wrong. But until someone actually try to use that .pc file, it's not a problem. > > I stated my technical opinion before, I can repeat it again: > > > > In this case library installs important metadata as a .pc file, and > > configure scripts of other applications read these .pc files to obtain > > the metadata, unable to configure for the library without them. The > > reading of .pc file is done using external program, pkg-config. >=20 > Some applications need pkg-config to extract the information from the > .pc file, others just link with the library without pkg-config. It is > not necessary to link with the library, it is necessary for some > applications to configure them during build time. Two different wordings of "get the build done". > > Here comes a heated debate, if library should provide all possible > > applications with a pkg-config, via it's runtime dependency, or if ever= y > > possible application should build depends on pkg-config. > > > > I believe that library should provide everything needed for other > > applications to be able to link the library. > > > > I believe that library should run depends on pkg-config. [ snippage of unrelated material ] > What references do you have to support your opinion? Will your next step be splitting include files to separate packages, because you don't need them to use the library, and instead make them build_depends of consumer applications? Besides, there are only 4525 ports depending on pkg-config now, are you going to check them all and each and decide whether they need pkg-config or not? Well, have a good fun. Also mind people building software outside of ports tree. Configure script failure when pkg-config is missing is not very obvious. Everyone somehow silently assume that when you have libxml2 in system, you also have pkg-config executable. I strongly believe in policy of minimal change of upstream code. Your proposal goes against this my belief. --=20 Pav Lucistnik Co vime o lasce? Laska je jako hruska. Hruska je sladka a ma urcity tvar. Zkuste presne definovat tvar hrusky. -- Marigold: Pul stoleti poezie