I mean the whole options fiasco in ports.
1. You can have an options file, which will be used to direct the
package's build, which is installed in to /var/db/ports (by default)
at the start of the build process. If you're trying to do unprivileged
builds, this is painful. If you're not using sudo with a decent time
limit for re-authentication (say by using su on a new machine) this is
excruciating
2. The options file is installed into /var/db/ports/www_nginx/options
and the file has the package build string embedded into it:
# This file is auto-generated by 'make config'.
# Options for nginx-1.10.3_1,2
_OPTIONS_READ=nginx-1.10.3_1,2
3. If the package version number does not match exactly what is
recorded there, you will get a dialog box appearing
4. You can also embed options in the MAKECONF (on FreeBSD, it's
/etc/make.conf). I could foresee issues with precedence here
5. We would now have to bootstrap dialog for menu provision in pkgsrc
bootstrap. Not a biggie, just considering what else we'd have to do to
apply this idea
6. In my experience, the BATCH thing hasn't worked in certain
circumstances. It may have been fixed recently.
7. I can't count the number of times I've gone away from a FreeBSD
machine and looked forward to a completed build by the time I came
back, only to find that version numbers don't match, and that,
instead, I have a dialog screen waiting for me
OK, so you'll admonish me for attacking the implementation, and not
the idea itself. So a few questions:
1. How do you record the option requested by the user for posterity?
In MAKECONF, in some form of dir hierarchy located where, and with
which permissions?
2. Is this choice temporary (i.e. throw away after package is built)
or long-term (i.e. record and all future builds will be done with
this)? Should it be both or neither?
3. Should we preserve options across version changes with a dialog?
4. Should user input take precedence over MAKECONF, or MAKECONF over
dialog?
5. I'd like to be able to run /etc on NetBSD as read-only, I don't
want to record package options in any other place. I now have issues
6. A simple timeout might solve many of the frustrations I have with
dialog. BUT how do you do option choice sanely in the presence of
timeouts. Automation should work for me, and I shouldn't have to be
checking up on it all the time.
In summary - our option choice is designed to be simple, and editable
by anyone with an editor and privileges. We have found, in the past,
that complexity causes issues. We assume some level of ability in most
people using a packaging system; whether that is warranted or not. If
someone knows enough to want HTTP_GZIP_STATIC in nginx, for example,
we expect them to be able to edit a file to choose that.
On 7 May 2018 at 17:41, Jason Bacon <outpaddling%yahoo.com@localhost
<mailto:outpaddling%yahoo.com@localhost>> wrote:
By "this" do you mean a menu to select package options, or an
option to enable non-portable compiler flags?
On 05/07/18 18:12, Alistair Crooks wrote:
In the remote possibility that this email is not a troll, I've
been looking at it for over 10 minutes now, and I seriously
cannot think why anyone would ever want anything even remotely
similar to this.
On 5 May 2018 at 12:31, Jason Bacon <outpaddling%yahoo.com@localhost
<mailto:outpaddling%yahoo.com@localhost> <mailto:outpaddling%yahoo.com@localhost
<mailto:outpaddling%yahoo.com@localhost>>> wrote:
Has anyone looked into providing something like FreeBSD's
dailog4ports for selecting package options?
E.g.
┌───────────────────────── plink-ng-g20180503
───────────────────────────┐
│. include "../../devel/binutils/buildlink3.mk"
CONFIGURE_ARGS+= --with-gnu-as --with-as=${PREFIX}/bin/gas
┌────────────────────────────────────────────────────────────────────┐
│
│ │ [x] NATIVE_CPU Optimize for this CPU (create
non-porable
binaries)│ │
│
└────────────────────────────────────────────────────────────────────┘
│
├────────────────────────────────────────────────────────────────────────┤
│ < OK > <Cancel> │
└────────────────────────────────────────────────────────────────────────┘