Bug 59254 - ports that write something after bsd.port.mk
Summary: ports that write something after bsd.port.mk
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Only Me
Assignee: Eitan Adler
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-11-13 15:20 UTC by Oliver Eikemeier
Modified: 2012-02-20 04:17 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Oliver Eikemeier 2003-11-13 15:20:13 UTC
Dear port maintainers,


included is a list of ports that write something after

  .include <bsd.port.mk>
  .include <bsd.port.post.mk>
  .include "${MASTERDIR}/Makefile"

or set MASTERDIR without being a slave port.

These are detected by version 2.4.8 of port devel/portlint, you can find 
referencs in the FreeBSD Porter's Handbook at: 

  http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/dads-after-port-mk.html
  http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/porting-masterdir.html

In most cases this is an attempt to work around the structure of bsd.port.mk.

Even though this may be an easy solution for the needs of your port, please 
think about an other way to do it.

Essentially all tools that work on the whole ports tree assume a certain 
uniformity in ports Makefiles, which goes beyond just compiling and installing 
without errors.

Non-adherence to standards makes it hard for people dealing with the ports 
tree as a whole, and hinders progress because small changes in bsd.port.mk may 
break your port.

If you do not know how to fix the port, ask at ports@FreeBSD.org or don't 
hesitate to contact me.

If there is currently no other way to do what you need for installing the 
port, this is an area where the bsd.port.mk has to be improved, and it is 
important that we get aware of this fact.

When there are only some comment lines at the end of the Makefile, please move 
or delete them. There is not FreeBSD standard that recommends ending a 
Makefile with '#EOF', and if not all ports do this it is of no use. I'm sorry 
if it hit some of Alan's ports with that, no disrespect intended.

Please excuse the inconvenience
-Oliver

Fix: 

clive@FreeBSD.org
 - chinese/bitchx
 - chinese/mutt

dinoex@FreeBSD.org
 - mail/sendmail

don@na.rim.or.jp
 - japanese/ruby-ming

eric@fractal.csie.org
 - chinese/links

fjoe@freebsd.org
 - databases/p5-DBD-Pg

girgen@pingpong.net
 - databases/postgresql7

gnome@FreeBSD.org
 - mail/mozilla-thunderbird
 - www/mozilla-firebird

honda@kashio.info.mie-u.ac.jp
 - japanese/ng-canna

jb.quenot@caraldi.com
 - www/resin2
 - www/resin3

jeh@FreeBSD.org
 - devel/arm-rtems-binutils
 - devel/arm-rtems-g77
 - devel/arm-rtems-gcc
 - devel/arm-rtems-gcj
 - devel/arm-rtems-gdb
 - devel/arm-rtems-objc
 - devel/i386-rtems-binutils
 - devel/i386-rtems-g77
 - devel/i386-rtems-gcc
 - devel/i386-rtems-gcj
 - devel/i386-rtems-gdb
 - devel/i386-rtems-objc
 - devel/i960-rtems-binutils
 - devel/i960-rtems-gcc
 - devel/i960-rtems-gdb
 - devel/m68k-rtems-binutils
 - devel/m68k-rtems-g77
 - devel/m68k-rtems-gcc
 - devel/m68k-rtems-gcj
 - devel/m68k-rtems-gdb
 - devel/m68k-rtems-objc
 - devel/mips-rtems-binutils
 - devel/mips-rtems-g77
 - devel/mips-rtems-gcc
 - devel/mips-rtems-gcj
 - devel/mips-rtems-gdb
 - devel/mips-rtems-objc
 - devel/powerpc-rtems-binutils
 - devel/powerpc-rtems-g77
 - devel/powerpc-rtems-gcc
 - devel/powerpc-rtems-gcj
 - devel/powerpc-rtems-gdb
 - devel/powerpc-rtems-objc
 - devel/sh-rtems-binutils
 - devel/sh-rtems-g77
 - devel/sh-rtems-gcc
 - devel/sh-rtems-gcj
 - devel/sh-rtems-gdb
 - devel/sh-rtems-objc
 - devel/sparc-rtems-binutils
 - devel/sparc-rtems-g77
 - devel/sparc-rtems-gcc
 - devel/sparc-rtems-gcj
 - devel/sparc-rtems-gdb
 - devel/sparc-rtems-objc

jihuang@gate.sinica.edu.tw
 - chinese/bind8

kde@freebsd.org
 - devel/qt-designer
 - devel/tinyq

knu@FreeBSD.org
 - japanese/ruby-romkan

lioux@FreeBSD.org
 - mail/qmail
 - sysutils/clockspeed

maho@FreeBSD.org
 - math/spooles-mpich
 - science/mpqc-mpich

mi@aldan.algebra.com
 - devel/tkp4

mita@FreeBSD.org
 - japanese/ghostscript-gnu-jpnfont
 - korean/ghostscript-gnu-korfont

nadav@cs.technion.ac.il
 - hebrew/pine

obrien@FreeBSD.org
 - shells/bash2
 - vietnamese/unicode-uhoai

openoffice@FreeBSD.org
 - portuguese/ooodict-pt_BR
 - portuguese/ooodict-pt_PT

orlando.bassotto@ieo-research.it
 - emulators/vmware3

ports@FreeBSD.org
 - audio/ermixer
 - databases/pydbdesigner
 - devel/cdialog
 - devel/invitation_to_ruby
 - devel/ossp-al
 - devel/ossp-cfg
 - devel/ossp-ex
 - devel/ossp-l2
 - devel/ossp-val
 - devel/ossp-var
 - devel/ruby-jttui
 - graphics/mgp-gallery
 - japanese/xvi-euc
 - japanese/xvi-sjis
 - net/ossp-sa
 - print/cups
 - print/cups-base
 - print/cups-lpr
 - sysutils/xstow
 - www/lynx-ssl

sada@FreeBSD.org
 - japanese/p5-manual

statue@freebsd.sinica.edu.tw
 - chinese/dictd

taguchi@tohoku.iij.ad.jp
 - x11-servers/XttXF86srv-common

tmutoh@mx10.freecom.ne.jp
 - japanese/ical

trevor@FreeBSD.org
 - audio/linux-mbrola

vanilla@FreeBSD.org
 - chinese/irssi

yatt@luna2.org
 - audio/timidity++-emacs

yssu@CCCA.NCTU.edu.tw
 - chinese/tin
Comment 1 Oliver Eikemeier freebsd_committer 2003-11-13 15:39:21 UTC
State Changed
From-To: open->feedback

I'll have to face the music 


Comment 2 Oliver Eikemeier freebsd_committer 2003-11-13 15:39:21 UTC
Responsible Changed
From-To: freebsd-ports-bugs->eik

I'll have to face the music
Comment 3 David E. O'Brien freebsd_committer 2003-11-13 16:47:41 UTC
On Thu, Nov 13, 2003 at 04:13:57PM +0100, Oliver Eikemeier wrote:
> included is a list of ports that write something after
> 
>   .include <bsd.port.mk>
>   .include <bsd.port.post.mk>
>   .include "${MASTERDIR}/Makefile"
...
> Even though this may be an easy solution for the needs of your port, please 
> think about an other way to do it.
...
> obrien@FreeBSD.org
>  - shells/bash2
>  - vietnamese/unicode-uhoai

Trust me I have tried to find other ways.  Please send patches.
For Bash yes bsd.port.mk is broken.  I've tried to get it fixed and I
don't care to fight that fight anymore.

-- 
-- David  (obrien@FreeBSD.org)
Comment 4 Oliver Eikemeier 2003-11-13 22:34:56 UTC
David O'Brien wrote:

>>Even though this may be an easy solution for the needs of your port, please 
>>think about an other way to do it.
>>[...]
>>obrien@FreeBSD.org
>> - shells/bash2
>> - vietnamese/unicode-uhoai
> 
> Trust me I have tried to find other ways.  Please send patches.
> For Bash yes bsd.port.mk is broken.  I've tried to get it fixed and I
> don't care to fight that fight anymore.

Hi David,

thank you for your quick feedback.  Please find attached the patches for both of
your Makefiles.  I hope they work, I couldn't really test unicode-uhoai,
unfortunately I don't speak vietnamese. You might want to check anyway, because
there is a `@dirrm lib/X11/fonts/TrueType/vietnamese-unicode' in pkg-plist, but
I couldn't find where the port created it.

You are right with CONFIGURE_TARGET, 359 ports use a workaround, thanks again
for bringing this up. I'm using this workaround myself in the OpenLDAP ports,
and PR 52917 seems to deal with it. At least it should be easy to remove the
workaround from those ports, they all use the same assignment, so it's just a
simple search-and-replace.

Regards
    Oliver

--- afterinclude.patch begins here ---
diff -u shells/bash2/Makefile.orig shells/bash2/Makefile
--- shells/bash2/Makefile.orig	19 May 2003 21:33:35 -0000
+++ shells/bash2/Makefile	13 Nov 2003 22:15:06 -0000
@@ -37,6 +37,8 @@
 CONFIGURE_ENV=	LDFLAGS=-static
 MAN1=		bash.1 bashbug.1
 
+CONFIGURE_TARGET=	--build=${MACHINE_ARCH}-portbld-freebsd${OSREL}
+
 .if defined(WITH_NET_REDIRECTIONS)
 CONFIGURE_ARGS+=	--enable-net-redirections
 .endif
@@ -63,5 +65,3 @@
 .endif
 
 .include <bsd.port.post.mk>
-
-CONFIGURE_TARGET:=	--build=${CONFIGURE_TARGET}
diff -u vietnamese/unicode-uhoai/Makefile.orig vietnamese/unicode-uhoai/Makefile
--- vietnamese/unicode-uhoai/Makefile.orig	7 Mar 2003 06:11:48 -0000
+++ vietnamese/unicode-uhoai/Makefile	13 Nov 2003 22:14:09 -0000
@@ -20,6 +20,8 @@
 USE_X_PREFIX=	yes
 NO_BUILD=	taken care of in do-install target
 
+EXTRACT_BEFORE_ARGS=	-qoL
+
 .include <bsd.port.pre.mk>
 
 BUILD_DEPENDS=	ttmkfdir:${PORTSDIR}/x11-fonts/ttmkfdir
@@ -36,5 +38,3 @@
 		${SH} ${PKGINSTALL} ${PKGNAME} POST-INSTALL
 
 .include <bsd.port.post.mk>
-
-EXTRACT_BEFORE_ARGS+=	-L
--- afterinclude.patch ends here ---
Comment 5 Kris Kennaway 2003-11-13 23:27:30 UTC
On Thu, Nov 13, 2003 at 11:34:56PM +0100, Oliver Eikemeier wrote:

> You are right with CONFIGURE_TARGET, 359 ports use a workaround, thanks 
> again
> for bringing this up. I'm using this workaround myself in the OpenLDAP 
> ports,
> and PR 52917 seems to deal with it. At least it should be easy to remove the
> workaround from those ports, they all use the same assignment, so it's just 
> a
> simple search-and-replace.

Unfortunately, that PR causes many more problems than it solves, and
the originator has not responded to requests to work on it.

Kris
Comment 6 David E. O'Brien freebsd_committer 2003-11-14 01:11:28 UTC
On Thu, Nov 13, 2003 at 11:34:56PM +0100, Oliver Eikemeier wrote:
> You are right with CONFIGURE_TARGET, 359 ports use a workaround, thanks
> again for bringing this up. I'm using this workaround myself in the
> OpenLDAP ports, and PR 52917 seems to deal with it. At least it should
> be easy to remove the workaround from those ports, they all use the
> same assignment, so it's just a simple search-and-replace.

Maybe we need a knob (USE_NEW_CONFIGURE_TUPLE) or something so that
there is complete consistency in the GNU tuple string.
Comment 7 Oliver Eikemeier 2003-11-14 01:27:08 UTC
David O'Brien wrote:

> On Thu, Nov 13, 2003 at 11:34:56PM +0100, Oliver Eikemeier wrote:
> 
>>You are right with CONFIGURE_TARGET, 359 ports use a workaround, thanks
>>again for bringing this up. I'm using this workaround myself in the
>>OpenLDAP ports, and PR 52917 seems to deal with it. At least it should
>>be easy to remove the workaround from those ports, they all use the
>>same assignment, so it's just a simple search-and-replace.
> 
> Maybe we need a knob (USE_NEW_CONFIGURE_TUPLE) or something so that
> there is complete consistency in the GNU tuple string.

OR make it dependend on GNU_CONFIGURE/HAS_CONFIGURE or use
GNU_CONFIGURE=	new
but we should discuss this as a followup of PR 52917
Comment 8 Oliver Eikemeier 2003-11-15 12:53:44 UTC
Hi David,

did you have a chance to try the patches I sent?
Comment 9 flz 2005-06-05 23:09:51 UTC
	Do we really have to keep this PR in GNATS ?

	It's been there for a long time and will probably never be 
	closed if we're waiting for all maintainer to fix their ports.

-- 
Florent Thoumie
flz@xbsd.org
Comment 10 krion 2005-06-07 10:53:09 UTC
On Mon, Jun 06, 2005 at 12:09:51AM +0200, Florent Thoumie wrote:
> 	Do we really have to keep this PR in GNATS ?
> 
> 	It's been there for a long time and will probably never be 
> 	closed if we're waiting for all maintainer to fix their ports.

If you feel it's impossible to implement it, just close or suspend it.

-Kirill
Comment 11 flz 2005-06-07 11:05:12 UTC
On Jun 7, 2005, at 11:53 AM, Kirill Ponomarew wrote:

> On Mon, Jun 06, 2005 at 12:09:51AM +0200, Florent Thoumie wrote:
>
>>     Do we really have to keep this PR in GNATS ?
>>
>>     It's been there for a long time and will probably never be
>>     closed if we're waiting for all maintainer to fix their ports.
>>
>
> If you feel it's impossible to implement it, just close or suspend it.

I talked to Clement about this issue. The point is not to just
close the PR. I don't think it's impossible to solve it but at
the moment we must ask ourselves if :

x is it a real problem to write things past bsd.port{,.post}.mk,
use USE_* before bsd.port.pre.mk, keep whitespaces instead of tabs.

  x if yes -> something must be done, the current approach is to
  wait for every maintainer to approve the change and it takes so
  long that the original submitter just give up or the patches don't
  apply. From what you can read in trevor's PR audit trail (#65409),
  everybody (or almost everybody) agree with this change. So i guess
  someone with the hat could either do the work or give blessing to
  someone else to do it, and he'll deal with unhappy maintainers.

  x if no -> just close the PR with a kind message.

x if you think it's just impossible, then better close it than
keep it for years.

That's IMO obviously.

Note: Apple Mail kinda sucks with line-wrapping, if shit happens
please just accept my excuses.

-- 
Florent Thoumie
flz@xbsd.org
Comment 12 krion 2005-06-07 11:10:02 UTC
On Tue, Jun 07, 2005 at 12:05:12PM +0200, Florent Thoumie wrote:
> On Jun 7, 2005, at 11:53 AM, Kirill Ponomarew wrote:
> 
> >On Mon, Jun 06, 2005 at 12:09:51AM +0200, Florent Thoumie wrote:
> >
> >>    Do we really have to keep this PR in GNATS ?
> >>
> >>    It's been there for a long time and will probably never be
> >>    closed if we're waiting for all maintainer to fix their ports.
> >>
> >
> >If you feel it's impossible to implement it, just close or suspend it.
> 
> I talked to Clement about this issue. The point is not to just
> close the PR. I don't think it's impossible to solve it but at
> the moment we must ask ourselves if :
> 
> x is it a real problem to write things past bsd.port{,.post}.mk,
> use USE_* before bsd.port.pre.mk, keep whitespaces instead of tabs.
> 
>  x if yes -> something must be done, the current approach is to
>  wait for every maintainer to approve the change and it takes so
>  long that the original submitter just give up or the patches don't
>  apply. From what you can read in trevor's PR audit trail (#65409),
>  everybody (or almost everybody) agree with this change. So i guess
>  someone with the hat could either do the work or give blessing to
>  someone else to do it, and he'll deal with unhappy maintainers.
> 
>  x if no -> just close the PR with a kind message.
> 
> x if you think it's just impossible, then better close it than
> keep it for years.
> 
> That's IMO obviously.

If those ports aren't broken by this change, I don't really care
what style Makefiles have.  Unfortunately nobody provided the
patches to test these changes on the cluster.

-Kirill
Comment 13 flz 2005-06-07 11:13:39 UTC
On Jun 7, 2005, at 12:10 PM, Kirill Ponomarew wrote:

> On Tue, Jun 07, 2005 at 12:05:12PM +0200, Florent Thoumie wrote:
>
>> On Jun 7, 2005, at 11:53 AM, Kirill Ponomarew wrote:
>>
>>
>>> On Mon, Jun 06, 2005 at 12:09:51AM +0200, Florent Thoumie wrote:
>>>
>>>
>>>>    Do we really have to keep this PR in GNATS ?
>>>>
>>>>    It's been there for a long time and will probably never be
>>>>    closed if we're waiting for all maintainer to fix their ports.
>>>>
>>>>
>>>
>>> If you feel it's impossible to implement it, just close or  
>>> suspend it.
>>>
>>
>> I talked to Clement about this issue. The point is not to just
>> close the PR. I don't think it's impossible to solve it but at
>> the moment we must ask ourselves if :
>>
>> x is it a real problem to write things past bsd.port{,.post}.mk,
>> use USE_* before bsd.port.pre.mk, keep whitespaces instead of tabs.
>>
>>  x if yes -> something must be done, the current approach is to
>>  wait for every maintainer to approve the change and it takes so
>>  long that the original submitter just give up or the patches don't
>>  apply. From what you can read in trevor's PR audit trail (#65409),
>>  everybody (or almost everybody) agree with this change. So i guess
>>  someone with the hat could either do the work or give blessing to
>>  someone else to do it, and he'll deal with unhappy maintainers.
>>
>>  x if no -> just close the PR with a kind message.
>>
>> x if you think it's just impossible, then better close it than
>> keep it for years.
>>
>> That's IMO obviously.
>>
>
> If those ports aren't broken by this change, I don't really care
> what style Makefiles have.  Unfortunately nobody provided the
> patches to test these changes on the cluster.

So we can take another approach.

It things work just fine now, do we really care for style so much
that we have to batch-fix these ports rather than fixing them in
the next update (i'm still asking if these PRs are really useful) ?

-- 
Florent Thoumie
flz@xbsd.org
Comment 14 Mark Linimon freebsd_committer freebsd_triage 2005-07-18 05:04:32 UTC
State Changed
From-To: feedback->suspended

With bugmeister hat on, reassign from inactive committer. 

This discussion of the problem that this PR brings to light never 
reached consensus.  I, personally, feel that it's a legitimate problem 
with the infrastructure, but I may be in the minority in this view. 

In any case unless someone wants to take up the banner and actually 
fix the infrastructure so these ports' hacks aren't necessary and/or 
submit patches to fix the individual ports so they can all be tested 
on the cluster, it's probably best to mark this as suspended. 


Comment 15 Mark Linimon freebsd_committer freebsd_triage 2005-07-18 05:04:32 UTC
Responsible Changed
From-To: eik->freebsd-ports-bugs
Comment 16 Mark Linimon freebsd_committer freebsd_triage 2007-05-16 22:43:17 UTC
Responsible Changed
From-To: freebsd-ports-bugs->linimon

I think that certain of these cases can now be addressed.  When I have 
time, I'll look at it.
Comment 17 Mark Linimon freebsd_committer freebsd_triage 2010-08-28 11:35:53 UTC
State Changed
From-To: suspended->open

I haven't worked on this in years.  Back to pool. 


Comment 18 Mark Linimon freebsd_committer freebsd_triage 2010-08-28 11:35:53 UTC
Responsible Changed
From-To: linimon->freebsd-ports-bugs
Comment 19 Alexander Best freebsd_committer 2010-09-03 00:55:10 UTC
Responsible Changed
From-To: freebsd-ports-bugs->portmgr

Assign to maintainer(s).
Comment 20 Eitan Adler freebsd_committer freebsd_triage 2012-02-15 17:03:42 UTC
Responsible Changed
From-To: portmgr->eadler

take with portmgr permission
Comment 21 Eitan Adler freebsd_committer freebsd_triage 2012-02-20 04:17:19 UTC
State Changed
From-To: open->closed

only 4 remaining of which 2 should not be fixed.