Bug 59254
| Summary: | ports that write something after bsd.port.mk | ||
|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Oliver Eikemeier <eikemeier> |
| Component: | Individual Port(s) | Assignee: | Eitan Adler <eadler> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | Latest | ||
| Hardware: | Any | ||
| OS: | Any | ||
State Changed From-To: open->feedback I'll have to face the music Responsible Changed From-To: freebsd-ports-bugs->eik I'll have to face the music 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) 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 ---
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
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.
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
Hi David, did you have a chance to try the patches I sent? 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 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
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 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
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 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. Responsible Changed From-To: eik->freebsd-ports-bugs 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. State Changed From-To: suspended->open I haven't worked on this in years. Back to pool. Responsible Changed From-To: linimon->freebsd-ports-bugs Responsible Changed From-To: freebsd-ports-bugs->portmgr Assign to maintainer(s). Responsible Changed From-To: portmgr->eadler take with portmgr permission State Changed From-To: open->closed only 4 remaining of which 2 should not be fixed. |
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