CRUX

The config file would be /etc/prt-get.conf and not /etc/pkgmk.conf, right? pkgmk doesn't care where you store ports afaik. Otherwise good stuff.

IMO we shouldn't use pkgmk.conf nor prt-get.conf for configuration of /usr/bin/ports. If we make ports configurable we should do that in /etc/ports.conf.

Note: other CRUX tools might have /usr/ports hard coded !

What's the advantage of using other directories than /usr/ports ?

I think it is a "security issue" to have external repositories choosing the destination directory. I've attached patches for rsync and httpup drivers to behave more like the git driver (use $PORTS_DIR/$(basename xxx)). Both patches take some forms of care regarding spaces. They don't fully address this issue. Still, as this is undecided, I've attach them here.

I see no advantage having different base directory for ports, as the symlinks gives enough flexibility, but only as long as the ports tool remain for root use only. I see no reason not to allow users to update, build and install ports to ~/bin. But this might be another issue.

It always struck me as odd that the rsync and httpup syncfiles define the target directory using an absolute path. It gives the impression that a regular user could just set the absolute path to a directory where they have write permission, and then run 'ports -u' to download an entire repository that they found on the portdb. If  FS#1852  had been implemented, they might have been able to do so.

> I see no advantage having different base directory for ports, as the symlinks gives enough flexibility, but only as long as the ports tool remain for root use only.

Restricting to UID 0 the use of 'ports -u' (but not 'ports -d' or 'ports -l') goes hand-in-hand with hard-coding the base directory. Note that the test for UID=0 can be satisfied without being real root; either by running 'fakeroot ports -u' or by switching to a new "user namespace" where one's actual UID is mapped to UID 0. Likewise the permissions and ownership of the base directory can be changed by the knowledgeable user, so nothing is lost by keeping it hard-coded in our tools. As long as we ship a set of tools whose defaults are internally consistent, we won't be flooded by support requests from less experienced users.

> I see no reason not to allow users to update, build and install ports to ~/bin.

Grabbing a random example from the portdb for illustration purposes, is this what you had in mind?
httpup sync https://raw.githubusercontent.com/akosela/crux-ports/master/#atari800 atari800
cd atari800 && pkgmk -d
mkdir -p $HOME/var/lib/pkg; touch $HOME/var/lib/pkg/db
pkgadd -r $HOME atari800*.pkg.gz

The last command probably needs to be prefaced by fakeroot (because pkgadd also performs a UID check), but installations to the $HOME of a regular user are outside the scope of the current ticket. This example just illustrates that the low-level {sync,build,install} tools can be exercised just fine by a regular user; it's only the high-level scripts like /usr/bin/ports and /etc/ports/drivers/{git,httpup,rsync} that would need to be customized for use by a regular user. I for one appreciate this separation. Keeping the base directory hard-coded in our high-level scripts, yet configurable by each syncfile that they parse, undermines this separation, which is one puzzling aspect of seeing absolute paths in /etc/ports/*.{rsync,httpup} and perhaps the motivation for the current ticket.