pkgsrc-Users archive

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

Re: Package options dialog

My original question "has anyone looked into this" was meant to be taken at face value.  I was simply curious whether any thought or effort had gone into this before.  I lot of energy is wasted when people read between the lines and respond to assumptions instead of the question as it was presented.

I had no implementation details in mind, but I would aim for something very simple and reliable over something with a lot of features.

Tech heads like us have a hard time seeing things through the eyes of a non-developer.  I've been reminded repeatedly by students and researchers how I take uncommon computer knowledge for granted. If I didn't have constant contact with them, I would not be able to empathize for long.

I'm approaching this with 18 years of experience supporting research computing, knowing what researchers tend to struggle with and what they can do well.  These are intelligent people, but most have not had attention to detail beaten into them to the extent that we have.  They tend to make a lot of mistakes with CLIs because they're used to more forgiving interfaces, so I aim to provide a more fool-proof interface if I'm suggesting that they do something for themselves.

Again, many researchers don't have a Unix guru available to do these things for them.  There aren't enough of us to go around, and many of them couldn't afford us anyway, so the only alternative is to make things like package managers more accessible to the somewhat-technically-challenged.

When I started using pkgsrc, I immediately realized that it had huge potential value to research, but the bootstrap process was way beyond the average scientist's skill level.   So I wrote auto-pkgsrc-setup, a "wizard" script to automate the setup process.  It's not perfect, but it has made pkgsrc more accessible.

They will make mistakes with the pkgsrc options interface as well.  A menu would prevent such mistakes, thus expediting their research and reducing the need for me to provide support.  This is why I raised the question.

If they find pkgsrc easy to use, it's a win for research, for NetBSD, and for the idea of portable software tools.  If they find it difficult, they'll gravitate to something easier and less portable like MacPorts, conda, EPEL, etc.

On 05/08/18 13:16, Alistair Crooks wrote:
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
              │.    include "../../devel/binutils/"
        CONFIGURE_ARGS+=        --with-gnu-as --with-as=${PREFIX}/bin/gas

              │ │ [x] NATIVE_CPU  Optimize for this CPU (create
            binaries)│ │
              │                     <  OK  > <Cancel>   │

Home | Main Index | Thread Index | Old Index