NetBSD Problem Report #21932
Received: (qmail 12960 invoked by uid 605); 19 Jun 2003 17:56:10 -0000
Message-Id: <200306191756.h5JHu3f20427@digital.clock.org>
Date: Thu, 19 Jun 2003 10:56:03 -0700 (PDT)
From: fair@netbsd.org
Sender: gnats-bugs-owner@netbsd.org
Reply-To: fair@netbsd.org
To: gnats-bugs@gnats.netbsd.org
Subject: pkgsrc should support CPUFLAGS from /etc/mk.conf
X-Send-Pr-Version: 3.95
>Number: 21932
>Category: pkg
>Synopsis: pkgsrc should support CPUFLAGS from /etc/mk.conf
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: pkg-manager
>State: open
>Class: change-request
>Submitter-Id: net
>Arrival-Date: Thu Jun 19 17:57:02 +0000 2003
>Closed-Date:
>Last-Modified: Mon May 23 02:50:01 +0000 2022
>Originator: Erik E. Fair
>Release: NetBSD-current
>Organization:
The NetBSD Project
>Environment:
>Description:
NetBSD sets its compilers to deliver maximum binary compatability
across the series of platforms that share a CPU, e.g. all NetBSD/alpha
systems have compilers that will compile to the 21064, the first alpha.
This is great for an initial install, and for installations that have
a wide range of a given family of systems which share binaries on NFS.
This practice also means we can support the widest range of systems
with one binary release per platform.
However, this practice also means that NetBSD does not take advantage
of performance enhancing improvements in the instruction sets of later
models of the Alpha, e.g. the 21164a, which has the BWX instructions.
In short, on single systems, we often do not perform as well as we
could. GCC 3.3 promises to make this disparity worse, by providing
more complete support for instruction sheduling, and CPU-specific
instruction generation.
In order to make it easier to compile CPU-specific binaries, Jason
Thorpe recently added CPUFLAGS to the /usr/share/mk/* files, as
distinct from CFLAGS, so that they can be easily included without
stomping on other things that are added to CFLAGS (e.g. optimization
flags).
I think that pkgsrc should support this also, to the extent that it
is possible to do within the confines of third-party supplied "make"
procedures which may or may not actually involve BSD make(1); it is
especially important that those third party applications which we
support perform as well as they can on the user's chosen platform when
the user chooses to optimize for that platform.
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
From: David Brownlee <abs@netbsd.org>
To: fair@netbsd.org
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: pkg/21932: pkgsrc should support CPUFLAGS from /etc/mk.conf
Date: Fri, 20 Jun 2003 17:14:01 +0100 (BST)
On Thu, 19 Jun 2003 fair@netbsd.org wrote:
> In order to make it easier to compile CPU-specific binaries, Jason
> Thorpe recently added CPUFLAGS to the /usr/share/mk/* files, as
> distinct from CFLAGS, so that they can be easily included without
> stomping on other things that are added to CFLAGS (e.g. optimization
> flags).
I was under the impression that COPTS could be used for this
purpose in the base system.
devel/cpuflags installs a cpuflags.mk file that sets CPU_FLAGS
then:
.ifdef BSD_PKG_MK # Try to catch various package opts
CFLAGS+=${CPU_FLAGS}
CXXFLAGS+=${CPU_FLAGS}
MAKE_FLAGS+=CCOPTIONS="${CPU_FLAGS}" # Override CCOPTIONS for imake
.else # Assume in base system, only COPTS
COPTS?=${CPU_FLAGS} ${DEFCOPTS}
# Include ${DEFCOPTS} and set ?= to allow overriding in kernel builds
.endif
I would suggest adding something like the following to bsd.pkg.mk:
.if defined(PKG_CPUFLAGS)
CFLAGS+=${PKG_CPUFLAGS}
CXXFLAGS+=${PKG_CPUFLAGS}
MAKE_FLAGS+=CCOPTIONS="${PKG_CPUFLAGS}" # Override CCOPTIONS for imake
.endif
That would allow people to set PKG_CPUFLAGS and CPUFLAGS
differently.
--
David/absolute -- www.netbsd.org: No hype required --
From: fredb@immanent.net (Frederick Bruckman)
To: fair@netbsd.org, abs@netbsd.org, fredb@netbsd.org
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: pkg/21932: pkgsrc should support CPUFLAGS from /etc/mk.conf
Date: Mon, 23 Jun 2003 12:43:19 -0500 (CDT)
In article <200306191756.h5JHu3f20427@digital.clock.org>,
fair@netbsd.org writes:
>
> In order to make it easier to compile CPU-specific binaries, Jason
> Thorpe recently added CPUFLAGS to the /usr/share/mk/* files, as
> distinct from CFLAGS, so that they can be easily included without
> stomping on other things that are added to CFLAGS (e.g. optimization
> flags).
>
> I think that pkgsrc should support this also, to the extent that it
> is possible to do within the confines of third-party supplied "make"
> procedures which may or may not actually involve BSD make(1)...
I agree completely. I'd even thought of doing something similiar to that.
From: David Brownlee <abs@netbsd.org>
To: fair@netbsd.org
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: pkg/21932: pkgsrc should support CPUFLAGS from /etc/mk.conf
Date: Fri, 20 Jun 2003 17:14:01 +0100 (BST)
....
I would suggest adding something like the following to bsd.pkg.mk:
.if defined(PKG_CPUFLAGS)
CFLAGS+=${PKG_CPUFLAGS}
CXXFLAGS+=${PKG_CPUFLAGS}
MAKE_FLAGS+=CCOPTIONS="${PKG_CPUFLAGS}" # Override CCOPTIONS for imake
.endif
That would allow people to set PKG_CPUFLAGS and CPUFLAGS
differently.
You can't... CPUFLAGS is automatically added to CFLAGS in <sys.mk> (for users
of NetBSD 1.6U and newer), so every package that respects CFLAGS should get
it already. Users can do the switch the ordinary way, with ".ifdef BSD_PKG_MK".
Given that, the place to add it for the other folks is in "bsd.prefs.mk".
More interesting, to me, is to find a way to distinguish the packages built
with submodel flags that would make them unusable on other hosts. I feel that
without this, a mixed collection will become unmanagable. My idea is to
install the package with the same name as before, but only munge the name of
the package tarball, by adding the contents of the "-march=" flag after the
version number. The "-march" tag, I think is adequate for this -- builders
of private collections can use that as a signal for less commonly used ABI
breakers, if desired.
The beauty of it, is, the dependency system in pkgsrc is ignorant of the
name of the original tarball, so it's not affected, and the point of putting
the tag after the version number, rather than before, is so that the wildcard
dependencies will mostly take care of matching the slightly changed name by
"pkg_add". (A few packages which don't use wildcards for dependencies would
need fixing.)
The following patch accomplishes this goal. Please test. The "pkg_add" part
only mostly works: You can leave the suffix off of the invocation of "pkg_add"
for the package you're installing directly, but for the dependencies in the
package to be found in $PKG_PATH, "pkg_add" says it can't find them, but then
installs them anyway. I guess "pkg_add" would need some fixing, too, perhaps,
even, to respect a preference for packages with certain $CPUFLAGS values?
Index: bsd.pkg.mk
===================================================================
RCS file: /cvsroot/pkgsrc/mk/bsd.pkg.mk,v
retrieving revision 1.1202
diff -u -r1.1202 bsd.pkg.mk
--- bsd.pkg.mk 2003/06/23 14:26:32 1.1202
+++ bsd.pkg.mk 2003/06/23 16:45:01
@@ -1069,7 +1069,7 @@
PKGREPOSITORYSUBDIR?= All
PKGREPOSITORY?= ${PACKAGES}/${PKGREPOSITORYSUBDIR}
-PKGFILE?= ${PKGREPOSITORY}/${PKGNAME}${PKG_SUFX}
+PKGFILE?= ${PKGREPOSITORY}/${PKGNAME}${CPUFLAGS:M-march=*:S/march=//}${PKG_SUFX}
CONFIGURE_DIRS?= ${WRKSRC}
CONFIGURE_SCRIPT?= ./configure
@@ -2246,15 +2246,15 @@
exit 1; \
fi; \
fi; \
- ${RM} -f ${PACKAGES}/$$cat/${PKGNAME}${PKG_SUFX}; \
- ${LN} -s ../${PKGREPOSITORYSUBDIR}/${PKGNAME}${PKG_SUFX} ${PACKAGES}/$$cat; \
+ ${RM} -f ${PACKAGES}/$$cat/${PKGNAME}${CPUFLAGS:M-march=*:S/march=//}${PKG_SUFX}; \
+ ${LN} -s ../${PKGREPOSITORYSUBDIR}/${PKGNAME}${CPUFLAGS:M-march=*:S/march=//}${PKG_SUFX} ${PACKAGES}/$$cat; \
done;
.endif
.if !target(delete-package-links)
delete-package-links:
${_PKG_SILENT}${_PKG_DEBUG}\
- ${FIND} ${PACKAGES} -type l -name ${PKGNAME}${PKG_SUFX} | ${XARGS} ${RM} -f
+ ${FIND} ${PACKAGES} -type l -name ${PKGNAME}${CPUFLAGS:M-march=*:S/march=//}${PKG_SUFX} | ${XARGS} ${RM} -f
.endif
.if !target(delete-package)
@@ -3116,7 +3116,7 @@
# Create a binary package from an install package using "pkg_tarup"
tarup:
${_PKG_SILENT}${_PKG_DEBUG} \
- ${RM} -f ${PACKAGES}/All/${PKGNAME}${PKG_SUFX}; \
+ ${RM} -f ${PACKAGES}/All/${PKGNAME}${CPUFLAGS:M-march=*:S/march=//}${PKG_SUFX}; \
${SETENV} PKG_DBDIR=${PKG_DBDIR} PKG_SUFX=${PKG_SUFX} \
PKGREPOSITORY=${PACKAGES}/All \
${LOCALBASE}/bin/pkg_tarup ${PKGNAME}; \
@@ -3124,7 +3124,7 @@
${MKDIR} ${PACKAGES}/$$CATEGORY; \
cd ${PACKAGES}/$$CATEGORY; \
${RM} -f ${PKGNAME}${PKG_SUFX}; \
- ${LN} -s ../All/${PKGNAME}${PKG_SUFX}; \
+ ${LN} -s ../All/${PKGNAME}${CPUFLAGS:M-march=*:S/march=//}${PKG_SUFX}; \
done
# shared code for replace and undo-replace
@@ -3172,7 +3172,7 @@
${ECHO_MSG} "*** WARNING - experimental target - data loss may be experienced ***"; \
oldpkgname=${PKGNAME}; \
newpkgname=`${CAT} ${WRKDIR}/.replace`; \
- replace_action="${SETENV} ${PKG_ADD} ${WRKDIR}/$$newpkgname${PKG_SUFX}"; \
+ replace_action="${SETENV} ${PKG_ADD} ${WRKDIR}/$$newpkgname${CPUFLAGS:M-march=*:S/march=//}${PKG_SUFX}"; \
${_REPLACE}; \
${RM} ${WRKDIR}/.replace
@@ -3552,8 +3552,8 @@
arch=${MACHINE_ARCH}; \
for site in ${BINPKG_SITES} ; do \
${ECHO} Trying `eval ${ECHO} $$site`/All ; \
- ${SHCOMMENT} ${ECHO} ${SETENV} PKG_PATH="`eval ${ECHO} $$site`/All" ${PKG_ADD} ${BIN_INSTALL_FLAGS} ${PKGNAME}${PKG_SUFX} ; \
- if ${SETENV} PKG_PATH="`eval ${ECHO} $$site`/All" ${PKG_ADD} ${BIN_INSTALL_FLAGS} ${PKGNAME}${PKG_SUFX} ; then \
+ ${SHCOMMENT} ${ECHO} ${SETENV} PKG_PATH="`eval ${ECHO} $$site`/All" ${PKG_ADD} ${BIN_INSTALL_FLAGS} ${PKGNAME}${CPUFLAGS:M-march=*:S/march=//}${PKG_SUFX} ; \
+ if ${SETENV} PKG_PATH="`eval ${ECHO} $$site`/All" ${PKG_ADD} ${BIN_INSTALL_FLAGS} ${PKGNAME}${CPUFLAGS:M-march=*:S/march=//}${PKG_SUFX} ; then \
${ECHO} "${PKGNAME} successfully installed."; \
break ; \
fi ; \
@@ -4200,7 +4200,7 @@
if [ ! -d ${PKG_DBDIR}/${PKGNAME} ]; then \
${ECHO_MSG} "${_PKGSRC_IN}> Registering installation for ${PKGNAME}"; \
${MKDIR} ${PKG_DBDIR}/${PKGNAME}; \
- ${PKG_CREATE} ${PKG_ARGS_INSTALL} -O ${PKGFILE} > ${PKG_DBDIR}/${PKGNAME}/+CONTENTS; \
+ ${PKG_CREATE} ${PKG_ARGS_INSTALL} -O ${PKGNAME}${PKG_SUFX} > ${PKG_DBDIR}/${PKGNAME}/+CONTENTS; \
${CP} ${DESCR} ${PKG_DBDIR}/${PKGNAME}/+DESC; \
${ECHO} ${COMMENT:Q} > ${PKG_DBDIR}/${PKGNAME}/+COMMENT; \
${CP} ${BUILD_VERSION_FILE} ${PKG_DBDIR}/${PKGNAME}/+BUILD_VERSION; \
@@ -4380,7 +4380,8 @@
# the contents of ${PLIST_SRC}.
#
GENERATE_PLIST?= ${TRUE};
-_GENERATE_PLIST= ${CAT} ${PLIST_SRC}; ${GENERATE_PLIST}
+_GENERATE_PLIST= ${ECHO} "@name " ${PKGNAME}; \
+ ${CAT} ${PLIST_SRC}; ${GENERATE_PLIST}
plist: ${PLIST}
${PLIST}: ${PLIST_SRC}
Index: bsd.prefs.mk
===================================================================
RCS file: /cvsroot/pkgsrc/mk/bsd.prefs.mk,v
retrieving revision 1.113
diff -u -r1.113 bsd.prefs.mk
--- bsd.prefs.mk 2003/06/05 00:23:29 1.113
+++ bsd.prefs.mk 2003/06/23 16:45:02
@@ -259,6 +259,11 @@
WHOLE_ARCHIVE_FLAG?= ${_OPSYS_WHOLE_ARCHIVE_FLAG}
NO_WHOLE_ARCHIVE_FLAG?= ${_OPSYS_NO_WHOLE_ARCHIVE_FLAG}
+# CPUFLAGS is automatically added to CFLAGS since about NetBSD 1.6U.
+.if ${OPSYS} != "NetBSD" || (!empty(OS_VERSION:M1.5*) || !empty(OS_VERSION:M1.6[_.A-T]*))
+CFLAGS+= ${CPUFLAGS}
+.endif
+
.ifndef DIGEST
DIGEST:= ${LOCALBASE}/bin/digest
MAKEFLAGS+= DIGEST=${DIGEST}
Frederick
From: David Brownlee <abs@netbsd.org>
To: Frederick Bruckman <fredb@immanent.net>
Cc: fair@netbsd.org, fredb@netbsd.org, gnats-bugs@gnats.netbsd.org
Subject: Re: pkg/21932: pkgsrc should support CPUFLAGS from /etc/mk.conf
Date: Tue, 24 Jun 2003 11:17:35 +0100 (BST)
On Mon, 23 Jun 2003, Frederick Bruckman wrote:
> More interesting, to me, is to find a way to distinguish the packages built
> with submodel flags that would make them unusable on other hosts. I feel that
> without this, a mixed collection will become unmanagable. My idea is to
> install the package with the same name as before, but only munge the name of
> the package tarball, by adding the contents of the "-march=" flag after the
> version number. The "-march" tag, I think is adequate for this -- builders
> of private collections can use that as a signal for less commonly used ABI
> breakers, if desired.
>
> The beauty of it, is, the dependency system in pkgsrc is ignorant of the
> name of the original tarball, so it's not affected, and the point of putting
> the tag after the version number, rather than before, is so that the wildcard
> dependencies will mostly take care of matching the slightly changed name by
> "pkg_add". (A few packages which don't use wildcards for dependencies would
> need fixing.)
>
> The following patch accomplishes this goal. Please test. The "pkg_add" part
> only mostly works: You can leave the suffix off of the invocation of "pkg_add"
> for the package you're installing directly, but for the dependencies in the
> package to be found in $PKG_PATH, "pkg_add" says it can't find them, but then
> installs them anyway. I guess "pkg_add" would need some fixing, too, perhaps,
> even, to respect a preference for packages with certain $CPUFLAGS values?
I tend to have the following in mk.conf
.ifdef LINTPKGSRC
PACKAGES=${PKGSRCDIR}/packages
.else
PACKAGES=${PKGSRCDIR}/packages/${OPSYS}-${OS_VERSION}-${LOWER_ARCH}${CPU_DIR}
.endif
${CPU_DIR} is set automatically by cpuflags.mk to ${CPU_FLAGS}
with spaces stripped, which can end up with things like
'-march=armv3m-mtune=strongarm' or '-m68040-msoft-float'
We already have a situation where by default building binary
packages from two different architectures will result in
a mismatched collection of packages in pkgsrc/packages. Could
I suggest we set ${CPU_DIR} or similar from ${CPUFLAGS} and
have PACKAGES as above?
--
David/absolute -- www.netbsd.org: No hype required --
From: Frederick Bruckman <fredb@immanent.net>
To: David Brownlee <abs@netbsd.org>
Cc: fair@netbsd.org, gnats-bugs@gnats.netbsd.org
Subject: Re: pkg/21932: pkgsrc should support CPUFLAGS from /etc/mk.conf
Date: Tue, 24 Jun 2003 10:33:58 -0500 (CDT)
On Tue, 24 Jun 2003, David Brownlee wrote:
> On Mon, 23 Jun 2003, Frederick Bruckman wrote:
>
> > More interesting, to me, is to find a way to distinguish the packages built
> > with submodel flags that would make them unusable on other hosts.
> I tend to have the following in mk.conf
>
> .ifdef LINTPKGSRC
> PACKAGES=${PKGSRCDIR}/packages
> .else
> PACKAGES=${PKGSRCDIR}/packages/${OPSYS}-${OS_VERSION}-${LOWER_ARCH}${CPU_DIR}
> .endif
Hmm. I think it was a mistake in the first place, not to have
${MACHINE_ARCH} embedded in the filename of the binary package, so I
wanted to see if it was possible to make that different from the
package name. I see that it is. Maybe we should just go all the way
with the idea, and put <machine-arch>-<submodel> in each package name?
> ${CPU_DIR} is set automatically by cpuflags.mk to ${CPU_FLAGS}
> with spaces stripped, which can end up with things like
> '-march=armv3m-mtune=strongarm' or '-m68040-msoft-float'
>
> We already have a situation where by default building binary
> packages from two different architectures will result in
> a mismatched collection of packages in pkgsrc/packages. Could
> I suggest we set ${CPU_DIR} or similar from ${CPUFLAGS} and
> have PACKAGES as above?
We have to be careful not to go too far. My favorite, this
week is, "-O2 -march=k6-2 -ffast-math -finline-functions
-maccumulate-outgoing-args -momit-leaf-frame-pointer".[*] The
only part of that that actually matters, compatibility-wise, is the
"-march=k6-2". Also keep in mind, that the user doesn't have to have
cpuflags installed to set such options, and we really don't want to
take chances that incompatible packages get mixed together on
ftp.netbsd.org. Therefore, I feel we should calculate the tag
in bsd.prefs.mk. Maybe something like this...?
CPU_TAG= ${CPUFLAGS:M-march=*:S/march=//}
CPU_TAG+= ${CPUFLAGS:M-m680*:S/-m//}
CPU_TAG+= ${CPUFLAGS:M-msoft-float=*:S/-m//}
...and then, of course, that gets inserted in all the places I've
already identified in the patch.
Frederick
[*] "-O3" turns on "-funroll-loops" and "-frename-registers", besides
"-finline-functions". The documention points out that "-funroll-loops"
isn't alway faster -- nor would you expect it to be -- and that
"-frename-registers" is most useful on a architecture with lots of
registers --- which i386 isn't. "-fomit-frame-pointer" doesn't even
compile all of the time -- but "-momit-leaf-frame-pointer" hasn't
given me any trouble, yet. "-maccumulate-outgoing-args" is
speculative; it certainly does make the binary 5 - 10% bigger than
without it (but not necessarily bigger than -funroll-loops), but I
haven't done any benchmarks, yet.
From: David Brownlee <abs@netbsd.org>
To: Frederick Bruckman <fredb@immanent.net>
Cc: fair@netbsd.org, gnats-bugs@gnats.netbsd.org
Subject: Re: pkg/21932: pkgsrc should support CPUFLAGS from /etc/mk.conf
Date: Thu, 26 Jun 2003 11:47:28 +0100 (BST)
On Tue, 24 Jun 2003, Frederick Bruckman wrote:
> On Tue, 24 Jun 2003, David Brownlee wrote:
>
> > On Mon, 23 Jun 2003, Frederick Bruckman wrote:
> >
> > > More interesting, to me, is to find a way to distinguish the packages built
> > > with submodel flags that would make them unusable on other hosts.
>
> > I tend to have the following in mk.conf
> >
> > .ifdef LINTPKGSRC
> > PACKAGES=${PKGSRCDIR}/packages
> > .else
> > PACKAGES=${PKGSRCDIR}/packages/${OPSYS}-${OS_VERSION}-${LOWER_ARCH}${CPU_DIR}
> > .endif
>
> Hmm. I think it was a mistake in the first place, not to have
> ${MACHINE_ARCH} embedded in the filename of the binary package, so I
> wanted to see if it was possible to make that different from the
> package name. I see that it is. Maybe we should just go all the way
> with the idea, and put <machine-arch>-<submodel> in each package name?
I would prefer to see at least machine_arch details in the
default PACKAGES directory, to somewhat match the binary
packages on ftp.netbsd.org, but that is not a strong
preference over embedding the details in the filename.
Either would be _much_ better than where we are now.
We should take this up on tech-pkg@ or packages@.
> > ${CPU_DIR} is set automatically by cpuflags.mk to ${CPU_FLAGS}
> > with spaces stripped, which can end up with things like
> > '-march=armv3m-mtune=strongarm' or '-m68040-msoft-float'
> >
> > We already have a situation where by default building binary
> > packages from two different architectures will result in
> > a mismatched collection of packages in pkgsrc/packages. Could
> > I suggest we set ${CPU_DIR} or similar from ${CPUFLAGS} and
> > have PACKAGES as above?
>
> We have to be careful not to go too far. My favorite, this
> week is, "-O2 -march=k6-2 -ffast-math -finline-functions
> -maccumulate-outgoing-args -momit-leaf-frame-pointer".[*] The
> only part of that that actually matters, compatibility-wise, is the
> "-march=k6-2". Also keep in mind, that the user doesn't have to have
> cpuflags installed to set such options, and we really don't want to
> take chances that incompatible packages get mixed together on
> ftp.netbsd.org. Therefore, I feel we should calculate the tag
> in bsd.prefs.mk. Maybe something like this...?
>
> CPU_TAG= ${CPUFLAGS:M-march=*:S/march=//}
> CPU_TAG+= ${CPUFLAGS:M-m680*:S/-m//}
> CPU_TAG+= ${CPUFLAGS:M-msoft-float=*:S/-m//}
>
> ...and then, of course, that gets inserted in all the places I've
> already identified in the patch.
Hum... don't forget at least -mcpu and -mipsX. I'm actually
inclined to put all the non default flags in the tag, so you
have an accurate record of what was used to compile the
package.
--
David/absolute -- www.netbsd.org: No hype required --
From: Benny Siegert <bsiegert@gmail.com>
To: gnats-bugs@netbsd.org, David Brownlee <abs@netbsd.org>
Cc:
Subject: Re: pkg/21932
Date: Sat, 4 Jul 2015 18:00:31 +0200
David, are you still interested in something like this?
From: David Brownlee <abs@netbsd.org>
To: Benny Siegert <bsiegert@gmail.com>
Cc: "gnats-bugs@netbsd.org" <gnats-bugs@netbsd.org>
Subject: Re: pkg/21932
Date: Fri, 17 Jul 2015 11:07:28 +0100
...maybe. I confess I'm not doing much with cpuflags recently...
On 4 July 2015 at 17:00, Benny Siegert <bsiegert@gmail.com> wrote:
> David, are you still interested in something like this?
From: Benny Siegert <bsiegert@gmail.com>
To: David Brownlee <abs@netbsd.org>
Cc: "gnats-bugs@netbsd.org" <gnats-bugs@netbsd.org>
Subject: Re: pkg/21932
Date: Sat, 25 Jul 2015 16:34:57 +0200
On Fri, Jul 17, 2015 at 12:07 PM, David Brownlee <abs@netbsd.org> wrote:
> ...maybe. I confess I'm not doing much with cpuflags recently...
Should I close it then, and you can reopen it in case?
From: David Brownlee <abs@netbsd.org>
To: Benny Siegert <bsiegert@gmail.com>
Cc: "gnats-bugs@netbsd.org" <gnats-bugs@netbsd.org>
Subject: Re: pkg/21932
Date: Mon, 27 Jul 2015 12:57:29 +0100
I think that would be best - thanks
On 25 July 2015 at 15:34, Benny Siegert <bsiegert@gmail.com> wrote:
> On Fri, Jul 17, 2015 at 12:07 PM, David Brownlee <abs@netbsd.org> wrote:
>> ...maybe. I confess I'm not doing much with cpuflags recently...
>
> Should I close it then, and you can reopen it in case?
From: "Erik E. Fair" <fair@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: pkg-manager@netbsd.org, gnats-admin@netbsd.org,
pkgsrc-bugs@netbsd.org
Subject: Re: pkg/21932
Date: Mon, 27 Jul 2015 12:14:51 -0700
Please do not close this problem report - it is not resolved.
Erik <fair@netbsd.org>
From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: pkg/21932
Date: Tue, 28 Jul 2015 08:14:33 +0000
On Mon, Jul 27, 2015 at 07:15:00PM +0000, Erik E. Fair wrote:
> Please do not close this problem report - it is not resolved.
Yes, that. Closing PRs just because they're old does not help anybody
or anything...
--
David A. Holland
dholland@netbsd.org
From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: pkg/21932
Date: Mon, 23 May 2022 02:45:09 +0000
Seven years ago, I wrote:
> On Mon, Jul 27, 2015 at 07:15:00PM +0000, Erik E. Fair wrote:
> > Please do not close this problem report - it is not resolved.
>
> Yes, that. Closing PRs just because they're old does not help anybody
> or anything...
That said, this PR is now old enough to vote, and reviewing it, it's
not entirely clear what the scope or intent is. The original report
was about honoring a base-system make setting in pkgsrc, which (taken
narrowly) is a bad idea, but for that purpose we have devel/cpuflags
now and I think the original request is long satisfied.
There's then some further discussion that seems to be about possible
ways of tagging specially-built binary packages, including some
infrastructure patches that are also now old enough to vote and almost
certainly impossible to merge.
My inclination would be to create a project page in the wiki about
binary package variant tagging (if there isn't one already, I might
have already written one years back), reference the material here
there so it can be found again, then close this PR as the original
request is handled.
Note that tagging binary packages for variant compiler options is a
special case and the problem really needs a general solution. (Other
things that binary package tagging should handle include option
settings, choice of compiler, native vs. pkgsrc X11, PREFER_PKGSRC
settings, choice of security mitigations/theater...)
Ideally it would be possible to have different variant builds of the
same package in the same binary package repo so users can pick what
they want. We've settled on a world where all this stuff is unlabelled
and each package repo is expected to be self-consistent; it works
adequately well but isn't as flexible as one might like.
--
David A. Holland
dholland@netbsd.org
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.46 2020/01/03 16:35:01 leot Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2020
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.