Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 21 Jul 2000 18:40:47 -0300
From:      "Mario Sergio Fujikawa Ferreira" <lioux@uol.com.br>
To:        CHOI Junho <cjh@kr.FreeBSD.org>
Cc:        freebsd-ports@freebsd.org
Subject:   Re: Ghostscript dependencies
Message-ID:  <20000721184047.A68315@Fedaykin.here>
In-Reply-To: <86hf9jllis.fsf@gradius.myhome>; from cjh@kr.FreeBSD.org on Fri, Jul 21, 2000 at 09:23:17PM %2B0900
References:  <20000720135834.A50109@Fedaykin.here> <86hf9jllis.fsf@gradius.myhome>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jul 21, 2000 at 09:23:17PM +0900, CHOI Junho wrote:
> >>>>> "MSFF" == Mario Sergio Fujikawa Ferreira <lioux@uol.com.br> writes:
> 
>     MSFF> Hi,
>     MSFF> Am I missing something or the later should
>     MSFF> be true:
> 
>     MSFF> diff -ruN /usr/ports/print/ggv/Makefile ggv/Makefile
>     MSFF> --- /usr/ports/print/ggv/Makefile	Sat Jun  3 04:35:01 2000
>     >  ggv/Makefile	Thu Jul 20 13:48:16 2000
>     MSFF> @@ -14,6 +14,7 @@
>     MSFF> MAINTAINER=	ade@FreeBSD.org
>  
>     MSFF> LIB_DEPENDS=	panel_applet.4:${PORTSDIR}/x11/gnomecore
>     > RUN_DEPENDS=    gs:${PORTSDIR}/print/ghostscript6
> 
> There is many ghostscripts ports, especially for language-specific
> ports(japanese/vfghostscript*, korean/*ghostscript). So dependency on
> ghostscript packages is not so good for such users. For example, I
> don't want to install gs6, because ko-ghostscript-httf does many thing
> for Korean printing.
> 
> You have *freedom* to choose your favorite ghostscript version(even
> old version!, or localized) for ports using ghostscript.
> 
> I think it's the reason that these ghostscript-related ports doesn't
> have dependency on only one ghostscript version.

	I understand your claim.
	However, we should try to think about someway to handle
this. IMHO, dependencies SHOULD be handled whenever possible.
Sometimes, even when not. :)
	That's one of the main purposes of this chibang we call
ports tree.
	Naive users, will install gv to find out it does
not work. Damn FreeBSD, it is broken. I will try that
graphic interface from RH.
	This is no joke.
	For you and all other expert users all around
who chose an specific version of ghostscript, the proposed
modification will not produce any problems. You already
have a binary called gs on your path, the build dependecy
check will ignore building ghostcript6 although not
adding the dependency correctly as I would have wished for.
	However, for those who just want to get it working
whatever it is (i.e., ghostview and family) the modification
is beneficial IMHO.
	One possible solution for this would be building
a inverted list indexing with our depedency checks:

	For instance, all ghostscript ports install gs.
All ghostscript dependent ports look for gs. We don't want
to be installing 2 gs or the port installation will be hosed
(if we do, I'll make another proposal in a future email).
	All ports have something they know other ports
will rely on for dependency checking be it a library
or whatever. We could add a directy inside Makefile
called (you guessed right) DEPENDS_{BUILD,FETCH,LIB,RUN}
which will contain the thing others will depend on. When
a port is installed, it will add it to the reverse index,
e.g., dbm based. Furthermore, this would a way to
tell porters about what is valid as a consistent
dependency for your port (something such a valid
port interface dependecy). :)
	When I try to be install ghostview, I will
check the apropriate database (_RUN) and I will find
there is a RUN_DEPENDS gs there pointing at
korean/*ghostscript. So it will know who to depend on
when adding both REQUIRED_BY and @pkgdep.
	The database would hold as a binary (as in 2-nary) key
both gs and PREFIX. Therefore, if I install 2 ghostscript{same,
different} ports in different prefixes with the
same DEPENDS_RUN: okay. If I try same prefix, NO. :) 
	Besides, all our {.*}_DEPENDS could stay,
the :part would stay as a default. If we don't have
anything on any database, we go with whatever is in the
_DEPENDS directive.
	However, I am probably oversimplifying the task, there are
consistency problems but the idea holds. Unfortunaly, I just thought
about it; therefore, I do not have an implementation to sample.
	Comments? Ideas? Please only constructive ones. Flames
should be directed to our beloved /dev/null.

	Regards,
		Mario Ferreira


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ports" in the body of the message




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