pkgsrc-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Package options dialog

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
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 <> 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 < <>> wrote:

    Has anyone looked into providing something like FreeBSD's
    dailog4ports for selecting package options?


      ┌───────────────────────── plink-ng-g20180503
      │ │ [x] NATIVE_CPU  Optimize for this CPU (create non-porable
    binaries)│ │
      │                     <  OK  > <Cancel>   │

Home | Main Index | Thread Index | Old Index