Bug 88528

Comment 1 Pav Lucistnik 2005-11-09 17:13:41 UTC

State Changed
From-To: open->feedback

This is not correct. Note that PKGNAMEPREFIX using slaves run depends on 
xemacs21-mule. That leads to duplication of plist. 

What is the difference between japanese/xemacs21-canna and editors/xemacs21-mule with CANNA defined? 

Comment 2 Pav Lucistnik 2005-11-09 17:13:41 UTC

Responsible Changed
From-To: freebsd-ports-bugs->pav

Poke

Comment 3 Pav Lucistnik 2005-11-13 13:56:10 UTC

NOKUBI Hirotaka p=ED=B9e v ne 13. 11. 2005 v 22:40 +0900:
> In message <200511091715.jA9HFHAM092583@freefall.freebsd.org>, Pav Lucist=
nik wr
> ites:
>=20
> >Synopsis: pkg-plist for ports/japanese/xemacs21-canna
> >
> >State-Changed-From-To: open->feedback
> >State-Changed-By: pav
> >State-Changed-When: Wed Nov 9 17:13:41 GMT 2005
> >State-Changed-Why:=20
> >This is not correct. Note that PKGNAMEPREFIX using slaves run depends on
> >xemacs21-mule. That leads to duplication of plist.
>=20
> I did not understand 'duplication of plist' means.
> I know that xemacs21-mule and xemacs21-canna (or other slaves) have
> almost same pkg-plist. Do you mean that?
>=20
> Would someone tell me more in detail?
> I wnat to make correct patch.

If you add PKGNAMEPREFIX to japanese/xemacs21-canna port, it will gain
dependency on editors/xemacs21-mule port, because
japanese/xemacs21-canna is a slave of editors/xemacs21-mule and
editors/xemacs21-mule contains this:

.if defined(PKGNAMEPREFIX)
RUN_DEPENDS+=3D   ${LOCALBASE}/lib/xemacs-${XEMACS_VER}/lisp/x-win-xfree86.=
elc:${PORTSDIR}/editors/xemacs21-mule
.endif

Now, if you add complete plist for japanese/xemacs21-canna, and it will
depend on editors/xemacs21-emacs, then same files except canna.elc will
be listed in both packages. That's illegal state.

> >What is the difference between japanese/xemacs21-canna and editors/xemac=
s21-mu
> >le with CANNA defined?
>=20
> About pkg-plist, difference is that including canna.elc, or not.
> Also, xemacs executable has difference.
> When CANNA is defined, it contains library routines for canna.

That does not answer my question.

Take these two ports:

1) japanese/xemacs21-canna
2) editors/xemacs21-mule with -DCANNA passed to make when building

What will be the different between the resulting packages?

My point is that all the canna logic should be in editors/xemacs21-mule
under CANNA variable, and japanese/xemacs21-canna should be only a dummy
slave port that passes CANNA to it's masterport. Correct?

--=20
Pav Lucistnik <pav@oook.cz>
              <pav@FreeBSD.org>

It also explains why paper clips just lie there while you look at them,
but as soon as you turn your back, they run away, giggling wildly,
and transform themselves into coat hangers.

In message <1131890170.14917.19.camel@localhost>, Pav Lucistnik writes:

>If you add PKGNAMEPREFIX to japanese/xemacs21-canna port, it will gain
>dependency on editors/xemacs21-mule port, because
>japanese/xemacs21-canna is a slave of editors/xemacs21-mule and
>editors/xemacs21-mule contains this:
>
>.if defined(PKGNAMEPREFIX)
>RUN_DEPENDS+=   ${LOCALBASE}/lib/xemacs-${XEMACS_VER}/lisp/x-win-xfree86.elc:$
>{PORTSDIR}/editors/xemacs21-mule
>.endif
>
>Now, if you add complete plist for japanese/xemacs21-canna, and it will
>depend on editors/xemacs21-emacs, then same files except canna.elc will
>be listed in both packages. That's illegal state.

Thank you, Pav. Now I understand.


>That does not answer my question.
>
>Take these two ports:
>
>1) japanese/xemacs21-canna
>2) editors/xemacs21-mule with -DCANNA passed to make when building
>
>What will be the different between the resulting packages?
>
>My point is that all the canna logic should be in editors/xemacs21-mule
>under CANNA variable, and japanese/xemacs21-canna should be only a dummy
>slave port that passes CANNA to it's masterport. Correct?

Exactly.

I attach new patch for japanese/xemacs21-canna.
With this patch, it will make complete PLIST.
So it's not broken now, I believe.

It seems that editors/xemacs-mule/pkg-plist contains wrong lines.
I put fixes for that too.

Comment 5 Pav Lucistnik 2005-11-19 20:41:53 UTC

State Changed
From-To: feedback->closed

Fixed.