Many ports defer setting of PKGNAMEPREFIX, basing it upon variables set in other parts of the ports infrastructure. This can result in differing values for ${OPTIONSFILE} between when the WITH_ and WITHOUT_ variables are set, and when the config target is run, meaning that any options set for such ports are ignored. How-To-Repeat: Consider www/mod_musicindex. Its Makefile contains: #v+ PKGNAMEPREFIX= ${APACHE_PKGNAMEPREFIX} ... USE_APACHE= 2.0+ #v- The WITH_ and WITHOUT_ variables are set before the bsd.apache.mk is included, giving an expansion of /var/db/ports/mod_musicindex/options for ${OPTIONSFILE}. However, when the config or showconfig targets are run, bsd.apache.mk has now been included, giving an expansion of /var/db/ports/ap20-mod_musicindex/options for ${OPTIONSFILE}. #v+ # cd /usr/ports/www/mod_musicindex # make rmconfig # make showconfig ===> The following configuration options are available for ap20-mod_musicindex-1.3.3_2: NLS=on (default) "Native language support" FLAC=off (default) "FLAC support" MP3=on (default) "MP3 support" MP4=off (default) "MP4 support" VORBIS=off (default) "Ogg/Vorbis support" LIBARCHIVE=on (default) "Archive downloading support" FILECACHE=on (default) "Caching support" ===> Use 'make config' to modify these settings # make -V WITH_MP4 # make -V WITHOUT_MP4 true # make config (enable MP4) # make showconfig ===> The following configuration options are available for ap20-mod_musicindex-1.3.3_2: NLS=on "Native language support" FLAC=off "FLAC support" MP3=on "MP3 support" MP4=on "MP4 support" VORBIS=off "Ogg/Vorbis support" LIBARCHIVE=on "Archive downloading support" FILECACHE=on "Caching support" ===> Use 'make config' to modify these settings # make -V WITH_MP4 # make -V WITHOUT_MP4 true # cp -r /var/db/ports/ap20-mod_musicindex /var/db/ports/mod_musicindex # make -V WITH_MP4 true # make -V WITHOUT_MP4 #v-
State Changed From-To: open->suspended Awaiting a patch.
Responsible Changed From-To: freebsd-ports-bugs->portmgr Bug against bsd.port.mk.
Dynamic PKGNAMEPREFIX is known to cause problems for py- ports with options. It's usually worked around by defining OPTIONSFILE. For www/mod_musicindex try to add OPTIONSFILE = ${PORT_DBDIR}/ap-${PORTNAME}/options
A crude survey shows several ports with this problem, listed below. There appear to be three different solutions used in other ports: explicitly setting OPTIONSFILE, explicitly setting UNIQUENAME, and explicitly setting LATEST_LINK. If you can suggest which is the preferred solution, I'll put together a patch. audio/mpdbrowser devel/py-gdata devel/py-twisted graphics/py-pycha news/py-pynzb security/py-keyring www/mod_accounting www/mod_dav www/mod_limitipconn www/mod_musicindex www/mod_security
Workaround for list of affected ports attached.
I was able to confirm that this issue is present at non-standard port depths, as well, and the fix is still valid. I maintain a portstree that resides at ${PORTSDIR}/local that has subcategories, as well, and by using the fix in the patch listed for other ports I was able to get this to work in my portstree by defining UNIQUENAME. May I please be added to the gnats notify for this problem report? Many thanks! -jgh -- Jason Helfman System Administrator experts-exchange.com http://www.experts-exchange.com/M_4830110.html E4AD 7CF1 1396 27F6 79DD 4342 5E92 AD66 8C8C FBA5
This is a multi-part message in MIME format.
State Changed From-To: suspended->open Patch generated and under test.
Responsible Changed From-To: portmgr->bapt Taken for exp-run
Responsible Changed From-To: bapt->beat Take for review and exp-run as discussed with bapt@.
Hi Matthew, Thanks a lot for your work on this. I made some tests and it looks good. Have you thought about consolidating UNIQUENAME and LATEST_LINK? The other thing I noticed is that the category is hardcoded. Like: UNIQUEPREFIX= archivers- Couldn't we used ${CATEGORY} for this to avoid redundant information? Thanks, Beat
On 27/07/2012 05:49, Beat Gätzi wrote: > Hi Matthew, > > Thanks a lot for your work on this. I made some tests and it looks good. > Have you thought about consolidating UNIQUENAME and LATEST_LINK? Yes. Bapt and I discussed that on IRC. LATEST_LINK will be pointless with pkgng, so it should disappear entirely quite soon. Until then, setting LATEST_LINK from the new UNIQUENAME seems like a good idea. > The other thing I noticed is that the category is hardcoded. Like: > UNIQUEPREFIX= archivers- > > Couldn't we used ${CATEGORY} for this to avoid redundant information? Oooh. Good catch. I don't always use the category name for the unique prefix, but where I do, that's sensible. Of course, that means generating ${CATEGORY} as the first word of ${CATEGORIES}. Which means that ${CATEGORIES} could be set automatically in very many ports. But that's something for another day. I'll post an updated patch quite soon. Ploughing through hundreds of Makefile eliminating now redundant LATEST_LINK usage is going to take some time. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey
2012/7/27 Matthew Seaman <matthew@freebsd.org>: > On 27/07/2012 05:49, Beat G=E4tzi wrote: >> Hi Matthew, >> >> Thanks a lot for your work on this. I made some tests and it looks good. >> Have you thought about consolidating UNIQUENAME and LATEST_LINK? > > Yes. Bapt and I discussed that on IRC. LATEST_LINK will be pointless > with pkgng, so it should disappear entirely quite soon. Ah yes, that's true. > Until then, setting LATEST_LINK from the new UNIQUENAME seems like a > good idea. Yes, although I'm a little bit afraid of changing existing LATEST_LINKs as = this may could break package handling with the old package tools. >> The other thing I noticed is that the category is hardcoded. Like: >> UNIQUEPREFIX=3D archivers- >> >> Couldn't we used ${CATEGORY} for this to avoid redundant information? > > Oooh. Good catch. I don't always use the category name for the unique > prefix, but where I do, that's sensible. Of course, that means > generating ${CATEGORY} as the first word of ${CATEGORIES}. Argh, that was too early when I wrote the mail. There is PKGCATEGORY which should be sufficient for this purpose. > Which means that ${CATEGORIES} could be set automatically in very many > ports. But that's something for another day. > > I'll post an updated patch quite soon. Ploughing through hundreds of > Makefile eliminating now redundant LATEST_LINK usage is going to take > some time. Great. Thanks a lot. I'll schedule an exp-run with the new patch so that you can commit this afterwards. Maybe we should describe this change in the CHANGES file and the porters handbook. Beat
Hi, The exp-run is finished but we have some fallout here: http://pointyhat.freebsd.org/errorlogs/amd64-9-exp-latest/ You can ignore the "fetch" errors as those were a problem of pointyhat. While checking the logs I generated some diffs of the changed directories: http://tmp.chruetertee.ch/ETCDIR.diff http://tmp.chruetertee.ch/EXAMPLESDIR.diff http://tmp.chruetertee.ch/DATADIR.diff http://tmp.chruetertee.ch/DOCSDIR.diff http://tmp.chruetertee.ch/WWWDIR.diff The unique directories are a huge advantage but I'm afraid that this will break a lot of things for users as conf files, temporary files of web application or other generated files move to other locations. So I see two possibilities: - We document each case some files move to a new location. - We just change UNIQUENAME and LATEST_LINK and cleanup everything else step by step afterwards. What do you think? Thanks, Beat
On 04/08/2012 09:06, Beat Gätzi wrote: > Hi, > > The exp-run is finished but we have some fallout here: > http://pointyhat.freebsd.org/errorlogs/amd64-9-exp-latest/ > > You can ignore the "fetch" errors as those were a problem of pointyhat. There doesn't seem to be any results there. > While checking the logs I generated some diffs of the changed directories: > http://tmp.chruetertee.ch/ETCDIR.diff > http://tmp.chruetertee.ch/EXAMPLESDIR.diff > http://tmp.chruetertee.ch/DATADIR.diff > http://tmp.chruetertee.ch/DOCSDIR.diff > http://tmp.chruetertee.ch/WWWDIR.diff > > The unique directories are a huge advantage but I'm afraid that this will > break a lot of things for users as conf files, temporary files of web > application or other generated files move to other locations. So I see two > possibilities: > - We document each case some files move to a new location. > - We just change UNIQUENAME and LATEST_LINK and cleanup everything else > step by step afterwards. > What do you think? All of the FOODIR variables are defined for every port, but not necessarily used by the port at all. There are also ports that use eg. what DATADIR would be without actually referencing the DATADIR variable -- here's an example from one of my own ports: -/usr/local/share/rt [...] +/usr/local/share/rt38 [...] -/usr/local/share/rt [...] +/usr/local/share/rt40 I can tell you that www/rt38 and www/rt40 already use ${LOCALBASE}/share/rt38 and ${LOCALBASE}/share/rt40 respectively, but there's no mention of DATADIR in those port's Makefiles. So I think there are really a lot fewer ports affected than your diff suggests. How about this: apply the changes to EXAMPLESDIR and DOCSDIR, which shouldn't have any functional effect. I don't think there's any need to bump portrevisions here either: we can let examples and docs changes be applied gradually as ports get updated over time. For ETCDIR, DATADIR and WWWDIR ultimately I'd love to do the 'document the files that have moved' thing[*]. Unfortunately I won't have any time to deal with this over the next month or so -- I'm going to be starting a new job soon and moving halfway across the country. So I guess for those variables revert the change for now, and plan on introducing them gradually later. Cheers, Matthew [*] Which means locating all the port specific Makefiles that reference any of those variables, cross-referencing that list against the diffs you generated, and then doing a before-and-after comparison of the actual packages. I can do the first two bits of that, certainly, but don't have the resources for the third bit. -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey
On Aug 4, 2012, at 11:27 AM, Matthew Seaman wrote: > On 04/08/2012 09:06, Beat G=E4tzi wrote: >> Hi, >>=20 >> The exp-run is finished but we have some fallout here: >> http://pointyhat.freebsd.org/errorlogs/amd64-9-exp-latest/ >>=20 >> You can ignore the "fetch" errors as those were a problem of = pointyhat. >=20 > There doesn't seem to be any results there. Works here. Pointyhat was down after I send the last mail so maybe you accessed the page when pointyhat was offline. >> While checking the logs I generated some diffs of the changed = directories: >> http://tmp.chruetertee.ch/ETCDIR.diff >> http://tmp.chruetertee.ch/EXAMPLESDIR.diff >> http://tmp.chruetertee.ch/DATADIR.diff >> http://tmp.chruetertee.ch/DOCSDIR.diff >> http://tmp.chruetertee.ch/WWWDIR.diff >>=20 >> The unique directories are a huge advantage but I'm afraid that this = will >> break a lot of things for users as conf files, temporary files of web >> application or other generated files move to other locations. So I = see two >> possibilities: >> - We document each case some files move to a new location. >> - We just change UNIQUENAME and LATEST_LINK and cleanup everything = else >> step by step afterwards. >=20 >> What do you think? >=20 > All of the FOODIR variables are defined for every port, but not > necessarily used by the port at all. There are also ports that use > eg. what DATADIR would be without actually referencing the DATADIR > variable -- here's an example from one of my own ports: >=20 > -/usr/local/share/rt > [...] > +/usr/local/share/rt38 > [...] > -/usr/local/share/rt > [...] > +/usr/local/share/rt40 >=20 > I can tell you that www/rt38 and www/rt40 already use > ${LOCALBASE}/share/rt38 and ${LOCALBASE}/share/rt40 respectively, but > there's no mention of DATADIR in those port's Makefiles. So I think > there are really a lot fewer ports affected than your diff suggests. Yes of course. I'll generate a list of affected ports by this change. > How about this: apply the changes to EXAMPLESDIR and DOCSDIR, which > shouldn't have any functional effect. I don't think there's any need = to > bump portrevisions here either: we can let examples and docs changes = be > applied gradually as ports get updated over time. Sounds good. > For ETCDIR, DATADIR and WWWDIR ultimately I'd love to do the 'document > the files that have moved' thing[*]. Unfortunately I won't have any > time to deal with this over the next month or so -- I'm going to be > starting a new job soon and moving halfway across the country. So I > guess for those variables revert the change for now, and plan on > introducing them gradually later. I will check how many ports are affected by the change and work on a new patch. Thanks, Beat=
On 07/08/2012 21:23, Beat Gätzi wrote: > On Aug 4, 2012, at 11:27 AM, Matthew Seaman wrote: >> On 04/08/2012 09:06, Beat Gätzi wrote: >>> The exp-run is finished but we have some fallout here: >>> http://pointyhat.freebsd.org/errorlogs/amd64-9-exp-latest/ >>> >>> You can ignore the "fetch" errors as those were a problem of pointyhat. >> >> There doesn't seem to be any results there. > > Works here. Pointyhat was down after I send the last mail so maybe you > accessed the page when pointyhat was offline. Yes -- that must have been the case. It's all back there now. I shall investigate and try and generate updates to the patch-set. > I will check how many ports are affected by the change and work on > a new patch. Excellent. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey
Responsible Changed From-To: beat->flo Exp-run finished. Some problems found: http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp.20121018130621/mysql-scripts-4.1.25.log http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp.20121018130621/mysql-scripts-5.0.95.log http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp.20121018130621/mysql-scripts-5.1.66.log http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp.20121018130621/percona-client-5.5.27.28.1.log Please review the other logs of the exp-run too: http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp.20121018130621/ Note: You can ignore all the fetch errors. Those were caused by the current work on the FreeBSD cluster.
Responsible Changed From-To: flo->beat Sorry, wrong pr...
State Changed From-To: open->closed Patch/PR is OBE for optionsng; please refile if this is still an issue
State Changed From-To: closed->open Re-opened as UNIQUENAME patch is still in the exp-run queue.
Responsible Changed From-To: beat->portmgr portmgr territory.
I didn't know about ports/148637 until bapt told me about it. I am copying and pasting my suggest from ports/175276. Here's my simple suggest to soltuion this issue. I think the OPTIONS needs to change from ${UNIQUENAME} to ${PKGORIGIN:S/\//_/}. It will be looked like "${PORT_DBDIR}/cat_port/options". Here's example: In bsd.options.mk: ----------------------------------- [...] OPTIONSFILE?= ${PORT_DBDIR}/${PKGORIGIN:S/\//_/}/options ----------------------------------- Then add compatible in somewhere like this: ----------------------------------- .if exist (${PORT_DBDIR}/${UNIQUENAME}/options) @${MV} ${PORT_DBDIR}/${UNIQUENAME} ${PORT_DBDIR}/${PKGORIGIN:S/\//_/} .endif ----------------------------------- Then teach the portmaster about if the port has been moved to the different category or renamed (by read MOVED) then change the ${PORT_DBDIR}/${PKGORIGIN:S/\//_/}. What do anyone think of my suggest solution? I haven't test anything at all, which it's just what I have in my mind right now. It doesn't need the complicate of UNIQUENAMEPREFIX and even don't need to modify all other ports. Just modify the OPTIONS framework, that's it. -- mezz.freebsd@gmail.com - mezz@FreeBSD.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gnome@FreeBSD.org
The above patch should fix the problem. http://people.freebsd.org/~bapt/yaf-options.diff Can anyone confirm? regards, Bapt
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I don't think this patch quite does the trick. From what I can tell, PKGORIGIN has not yet been defined by the time bsd.options.mk evaluates OPTIONSFILE and OPTIONS_FILE. For example, in print/py-reportlab2, make config writes /var/db/ports/print_py-reportlab2/options but immediately thereafter, make config-conditional tries to read /var/db/ports/reportlab2/options for OPTIONSFILE, and then /var/db/ports//options for OPTIONS_FILE. I am not able to propose a revision to your patch, but will gladly test upon request. Thank you for giving it your attention. Regards, John -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJRtpFvAAoJEBRzAKlhyP/FQYIIALjNcHWXESHNTAyIZsHO3CJE QgIWqJLTIM652GGlFqdN1UOI/DqItYVom17Ti3UQ+6zOEOpCNLezsVqqUjjNKDcG WtzuuBfwwVVBDEzzis+x8Bd1pxlrkfjlbfU0Uico+N45oL2hxi+g2eljlrt9L/O/ cNLTN9fVkl49B5spckNKUHzt+Q+q+WqfWSN5qwqQj/bjzgailLqSkQNArGmf0Swj GYdmtskfgkF/DOB5VIMjbOxb7ORLotXyiYrS83BK1reg7HyyWL+UhT26BA7Px0/W 6qoApjfigghFhPMzgxIS8u4mzDxmMqv5PBAxqmuL3L2ZOlTv1jZzaPdebCVysy8= =yc9y -----END PGP SIGNATURE-----
Your are totally right, good catch! Here is a new version which makes sure to define PKGORIGIN earlier :) http://people.freebsd.org/~bapt/yaf-options.patch regards, Bapt
Bapt, This is looking pretty good. I have tested the following use cases with net/wireshark, a port that is not affected by the PKGNAMEPREFIX problem. I also tested cases 1 and 3 with print/py-reportlab2, which is affected. 1. Neither OPTIONSFILE nor OPTIONS_FILE exists. PASS: Reads nothing and creates OPTIONS_FILE. Becomes case 3. 2. OPTIONSFILE exists, but OPTIONS_FILE does not. PASS: Reads OPTIONSFILE, creates OPTIONS_FILE. Becomes case 4. 3. OPTIONSFILE does not exist, but OPTIONS_FILE does. PASS: Reads OPTIONS_FILE, updates OPTIONS_FILE. Remains case 3. 4. Both OPTIONSFILE and OPTIONSFILE exist. PASS: Reads OPTIONS_FILE, updates OPTIONS_FILE. Remains case 4. How will this patch affect management tools (portmaster, portupdate, pkg)? What is the destiny of the stale OPTIONSFILEs? Regards, John
Author: bapt Date: Wed Jun 26 07:22:06 2013 New Revision: 321785 URL: http://svnweb.freebsd.org/changeset/ports/321785 Log: Replace OPTIONSFILE by OPTIONS_FILE which is a more robust variable with unicity insurance in its path to avoid collision. A compatibility layer is available to automatically load and migration from OPTIONSFILE to OPTIONS_FILE (this is all transparent for users.) It is recommanded that ports that used to overwrite OPTIONSFILE to prevent the known bugs should keep the OPTIONSFILE overwrite for a while (6 month) to allow the migration to happen automatically and users to not lose their old save options. New options file is now based on the PKGORIGIN therefor the definition of the PKGORIGIN has been moved ealier in bsd.port.mk to allow it's usage from withing bsd.options.mk PR: ports/148637 Reviewed by: bdrewery Modified: head/Mk/bsd.options.mk head/Mk/bsd.port.mk Modified: head/Mk/bsd.options.mk ============================================================================== --- head/Mk/bsd.options.mk Wed Jun 26 07:10:28 2013 (r321784) +++ head/Mk/bsd.options.mk Wed Jun 26 07:22:06 2013 (r321785) @@ -75,7 +75,9 @@ .if !defined(OPTIONSMKINCLUDED) OPTIONSMKINCLUDED= bsd.options.mk +OPTIONS_NAME?= ${PKGORIGIN:S/\//_/} OPTIONSFILE?= ${PORT_DBDIR}/${UNIQUENAME}/options +OPTIONS_FILE?= ${PORT_DBDIR}/${OPTIONS_NAME}/options # Set the default values for the global options, as defined by portmgr .if !defined(NOPORTDOCS) @@ -162,6 +164,7 @@ PORT_OPTIONS:= ${PORT_OPTIONS:N${opt}} NEW_OPTIONS:= ${NEW_OPTIONS:N${opt}} . endfor +# XXX To remove once UNIQUENAME will be removed ## Set the options specified per-port (set by user in make.conf) . for opt in ${${UNIQUENAME}_SET} . if !empty(COMPLETE_OPTIONS_LIST:M${opt}) @@ -175,7 +178,22 @@ NEW_OPTIONS:= ${NEW_OPTIONS:N${opt}} PORT_OPTIONS:= ${PORT_OPTIONS:N${opt}} NEW_OPTIONS:= ${NEW_OPTIONS:N${opt}} . endfor +# XXX To remove once UNIQUENAME will be removed +## Set the options specified per-port (set by user in make.conf) +. for opt in ${${OPTIONS_NAME}_SET} +. if !empty(COMPLETE_OPTIONS_LIST:M${opt}) +PORT_OPTIONS+= ${opt} +. endif +. endfor +PORT_OPTIONS:= ${PORT_OPTIONS:O:u} + +## Unset the options excluded per-port (set by user in make.conf) +. for opt in ${${OPTIONS_NAME}_UNSET} +PORT_OPTIONS:= ${PORT_OPTIONS:N${opt}} +. endfor + +# XXX to remove once UNIQUENAME is removed ## options files (from dialog) . if exists(${OPTIONSFILE}) && !make(rmconfig) . include "${OPTIONSFILE}" @@ -183,6 +201,15 @@ NEW_OPTIONS:= ${NEW_OPTIONS:N${opt}} . if exists(${OPTIONSFILE}.local) . include "${OPTIONSFILE}.local" . endif +# XXX to remove once UNIQUENAME is removed + +## options files (from dialog) +. if exists(${OPTIONS_FILE}) && !make(rmconfig) +. include "${OPTIONS_FILE}" +. endif +. if exists(${OPTIONS_FILE}.local) +. include "${OPTIONS_FILE}.local" +. endif ### convert WITH and WITHOUT found in make.conf or reloaded from old optionsfile .for opt in ${ALL_OPTIONS} Modified: head/Mk/bsd.port.mk ============================================================================== --- head/Mk/bsd.port.mk Wed Jun 26 07:10:28 2013 (r321784) +++ head/Mk/bsd.port.mk Wed Jun 26 07:22:06 2013 (r321785) @@ -1217,6 +1217,13 @@ WITH_PKGNG?= yes # Only define tools here (for transition period with between pkg tools) .include "${PORTSDIR}/Mk/bsd.commands.mk" +.for _CATEGORY in ${CATEGORIES} +PKGCATEGORY?= ${_CATEGORY} +.endfor +_PORTDIRNAME= ${.CURDIR:T} +PORTDIRNAME?= ${_PORTDIRNAME} +PKGORIGIN?= ${PKGCATEGORY}/${PORTDIRNAME} + MASTERDIR?= ${.CURDIR} .if ${MASTERDIR} != ${.CURDIR} @@ -2385,14 +2392,6 @@ TMPPLIST?= ${WRKDIR}/.PLIST.mktmp TMPPLIST_SORT?= ${WRKDIR}/.PLIST.mktmp.sorted TMPGUCMD?= ${WRKDIR}/.PLIST.gucmd -.for _CATEGORY in ${CATEGORIES} -PKGCATEGORY?= ${_CATEGORY} -.endfor -_PORTDIRNAME= ${.CURDIR:T} -PORTDIRNAME?= ${_PORTDIRNAME} -PKGORIGIN?= ${PKGCATEGORY}/${PORTDIRNAME} - - .if !defined(PKG_ARGS) PKG_ARGS= -v -c -${COMMENT:Q} -d ${DESCR} -f ${TMPPLIST} -p ${PREFIX} -P "`cd ${.CURDIR} && ${MAKE} actual-package-depends | ${GREP} -v -E ${PKG_IGNORE_DEPENDS} | ${SORT} -u -t : -k 2`" ${EXTRA_PKG_ARGS} $${_LATE_PKG_ARGS} .if !defined(NO_MTREE) @@ -6106,13 +6105,20 @@ do-config: @${ECHO_MSG} "===> No options to configure" .else .if ${UID} != 0 && !defined(INSTALL_AS_USER) - @optionsdir=${OPTIONSFILE}; optionsdir=$${optionsdir%/*}; \ + @optionsdir=${OPTIONS_FILE}; optionsdir=$${optionsdir%/*}; \ + oldoptionsdir=${OPTIONSFILE}; oldoptionsdir=$${oldoptionsdir%/*}; \ ${ECHO_MSG} "===> Switching to root credentials to create $${optionsdir}"; \ - (${SU_CMD} "${SH} -c \"${MKDIR} $${optionsdir} 2> /dev/null\"") || \ + (${SU_CMD} "${SH} -c \"if [ -d $${oldoptionsdir} -a ! -d $${optionsdir} ]; then ${MV} $${oldoptionsdir} $${optionsdir}; elif [ -d $${oldoptionsdir} -a -d $${optionsdir} ]; then ${RM} -rf $${oldoptionsdir} ; fi ; ${MKDIR} $${optionsdir} 2> /dev/null\"") || \ (${ECHO_MSG} "===> Cannot create $${optionsdir}, check permissions"; exit 1); \ ${ECHO_MSG} "===> Returning to user credentials" .else - @(optionsdir=${OPTIONSFILE}; optionsdir=$${optionsdir%/*}; \ + @(optionsdir=${OPTIONS_FILE}; optionsdir=$${optionsdir%/*}; \ + oldoptionsdir=${OPTIONSFILE}; oldoptionsdir=$${oldoptionsdir%/*}; \ + if [ -d $${oldoptionsdir} -a ! -d $${optionsdir} ]; then \ + ${MV} $${oldoptionsdir} $${optionsdir}; \ + elif [ -d $${oldoptionsdir} -a -d $${optionsdir} ]; then \ + ${RM} -rf $${oldoptionsdir} ; \ + fi ; \ ${MKDIR} $${optionsdir} 2> /dev/null) || \ (${ECHO_MSG} "===> Cannot create $${optionsdir}, check permissions"; exit 1) .endif @@ -6144,11 +6150,11 @@ do-config: fi; \ done; \ if [ ${UID} != 0 -a "x${INSTALL_AS_USER}" = "x" ]; then \ - ${ECHO_MSG} "===> Switching to root credentials to write ${OPTIONSFILE}"; \ - ${SU_CMD} "${CAT} $${TMPOPTIONSFILE} > ${OPTIONSFILE}"; \ + ${ECHO_MSG} "===> Switching to root credentials to write ${OPTIONS_FILE}"; \ + ${SU_CMD} "${CAT} $${TMPOPTIONSFILE} > ${OPTIONS_FILE}"; \ ${ECHO_MSG} "===> Returning to user credentials"; \ else \ - ${CAT} $${TMPOPTIONSFILE} > ${OPTIONSFILE}; \ + ${CAT} $${TMPOPTIONSFILE} > ${OPTIONS_FILE}; \ fi; \ ${RM} -f $${TMPOPTIONSFILE} @cd ${.CURDIR} && ${MAKE} sanity-config @@ -6242,6 +6248,19 @@ rmconfig: ${RM} -f ${OPTIONSFILE}; \ ${RMDIR} $${optionsdir} 2>/dev/null || return 0; \ fi +.endif +.if exists(${OPTIONS_FILE}) + -@${ECHO_MSG} "===> Removing user-configured options for ${PKGNAME}"; \ + optionsdir=${OPTIONS_FILE}; optionsdir=$${optionsdir%/*}; \ + if [ ${UID} != 0 -a "x${INSTALL_AS_USER}" = "x" ]; then \ + ${ECHO_MSG} "===> Switching to root credentials to remove ${OPTIONS_FILE} and $${optionsdir}"; \ + ${SU_CMD} "${RM} -f ${OPTIONS_FILE} ; \ + ${RMDIR} $${optionsdir}"; \ + ${ECHO_MSG} "===> Returning to user credentials"; \ + else \ + ${RM} -f ${OPTIONS_FILE}; \ + ${RMDIR} $${optionsdir} 2>/dev/null || return 0; \ + fi .else @${ECHO_MSG} "===> No user-specified options configured for ${PKGNAME}" .endif _______________________________________________ svn-ports-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-ports-all To unsubscribe, send any mail to "svn-ports-all-unsubscribe@freebsd.org"
State Changed From-To: open->closed Fixed now.